Re: [JXTA discuss] IP mobility

I am sorry, a stupid question. What the pl stands for?

Giorgis Georgakoudis

----- Original Message -----
From: "Mohamed Abdelaziz" <[email protected]>
To: <[email protected]>
Sent: Friday, July 22, 2005 1:39 AM
Subject: 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]