<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><br><br><br><br><br><div></div><div id="divNeteaseMailCard"></div><br><pre><br>At 2014-07-11 07:09:52, "Pavel Emelyanov" <xemul@parallels.com> wrote:
>On 07/11/2014 10:00 AM, ΛοΡΗ wrote:
>> Hi there:
>> In order to implement the migration with changing the ip to the target machine where the program migrates
>> to , I add a arg option '-m' in main function in crtools.c and add some code to limit the -m option only
>> valid in restore operation. And I add a data member in opts struct defined in cr_option.h.
>>
>> When the user use the command like this:
>>
>> '''criu restore -D targetFiles -m 192.168.0.1 --tcp-established '''
>>
>> the ip will be changed into 192.168.0.1 in function restore_sockaddr in sk-inet.c.
>
<div>>But there can be many sockets, which of them will have the ip changed into 192.168.0.1?</div><div>It depends on whether the all sockets to be restored are handled by function resotre_sockaddr.If it is , then all the sockets will be changed into 192.168.0.1.And according to my test , it is.</div>>
>> Of course , the program will be restored , but the tcp connection will be disconnected because of the changing
>> of the ip. And for the program , there should be error handling code for this scenario.
>
<div>>Maybe it's just better to close the connection while restoring instead of fixing the ip address?</div><div><br></div><div>Yep, it is what <span style="color: rgb(51, 51, 51); font-size: 13px; line-height: 20.020000457763672px; white-space: normal;">Berkeley C/R system does, which doesn't support the restoring the socket aspect. </span><span style="line-height: 1.7;">I guess if we close the connection during dumping , there should be a complex strategy for restoring the connections ,including: 1)allowing the user to indicate the IP they want to migrate to 2)allowing the user to decide which IP should be assigned to which socket. 3) the packages in the queue of current connection will be dropped ,if there is no way to redirect them into new connection and make them consistent with the other end of the connection.</span></div><div><span style="line-height: 1.7;">I guess , it's difficult to know how to reconnect to the server program with new IPs in CRIU. And in fact , the complex step for user is the step 2) , which also could not be avoided if we want to acheive dumping and restoring tcp connection in CRIU.</span></div><div><span style="line-height: 1.7;">At the same time , We could not avoid step 3) either. So what we do now is that we decide to let the developer of the client program to handle this situation.But before they can use the error handling code to deal with the situation above , firstly we need to have the program restored.So we changed the IP and restore the program ,which will detect the broken connection and do their error handling code,such as reconnecting or exitting, after retoration.</span></div><div><span style="line-height: 1.7;"><br></span></div><div><span style="line-height: 1.7;">In one word , what we do is just give the program a trigger to handle this situation , but what need to do is decided by the client program.</span></div><div><span style="line-height: 1.7;">By the way , after the discussion by us , we don't think the TCP connection restoration is rational in all situations , especially migration .Even thoughyou could restore the one end of connection , but if you could not restore the other end of the connection , an inconsitent situation between the two ends appears , which will go against the TCP/IP principle.</span></div><div><br></div>>> By the way , if there is not -m option in command, the program will be restored in the original way.
>> Finally, I patched the three files. But what should be noticed , the command to patch the files:
>>
>> '''diff -uN fromFile toFile > file.patch'''
>
>Git makes this much simpler :) Below is the link on a page describing how to do it.
>
>> the fromFile is from the criu-1.3-rc1 , and the toFile is from the criu-1.3-rc2.
>> The whole story will be seen: https://bugzilla.openvz.org/show_bug.cgi?id=2988
>> If there is any problem , please let me know.
>
>Can you send the patch in the format described at http://criu.org/How_to_submit_patches
<div>>Briefly -- the patch should be inline (viewable in the mailer) and with signed-off-by line.</div><div>Sure, I will have done it as soon as possible.</div>>
>> The attachment is the patch files.
>> Thanks
>>
>> Ya Sun
>
>Thanks,
>Pavel
>
</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>