Re: [JXTA discuss] IP mobility

I revisited the tcp transport and it appears that the incoming server 
thread can deal with a closed ServerSocket (due to an ip address 
change), and continue accepting connections, however I don't see any 
code which updates a peers access point advertisement with the new 
physical address.  It's very likely that back channels are used to 
establish communication. otherwise the sending peer would have been able 
resume communication just fine without having to re-resolve the pipe.

ps -- query for pipe --> pl
pl --  connects  to ps, sends pipe resolver response --> ps
ps -- uses back channel (the above connection) to create a messenger --> pl

IncomingUnicastServer needs to detect this change (beyond closure 
detection), and notify the endpoint router of the change. Then we would 
have "hot mobility" support. I'll see what can be done, at which point I 
will look for you to run some tests.

Mohamed

Giorgos Georgakoudis wrote:

> Hello,
>  
> Mohamed we had a conservation yesterday about how the network 
> interface changes reflect on jxta. If I remembered correctly on direct 
> connections you mentioned that the jxta java binding cannot cope with 
> ip changes but using a relay peer there is no problem. Please correct 
> me if I am wrong.


When using a relay, other peers can send a message to a peer's virtual 
address (the relay) when physical addresses are invalid. Retrieving 
messages (outbound connections) are not affected by any interface 
address change.


>  
> I created a test program where there is PipeListener and a PipeSender. 
> Without a relay peer I started the communication (PipeSender sends a 
> hello message every 2 seconds). Then I disconnected and reconnected 
> the PipeListener (observing an IP change) and it works! The only 
> "trick" I used is that a create an OutputPipe for every hello 
> message I sent using createOutputPipe() in PipeService with a timeout 
> that retries when it fails to create one using the same pipe 
> advertisement that I discovered before otherwise by creating one 
> OutputPipe since the beginning of the comm I would get an exception 
> saying Pipe Closed. So internally Jxta routing protocol gets informed 
> about the network interface changes for a give peer id, right?
>  
> Best regards,
>  
> Giorgis Georgakoudis
>  

-- 
http://blogs.sun.com/roller/page/hamada
http://weblogs.java.net/blog/hamada