Re: [JXTA discuss] NEW Re: [JXTA discuss] Mobile IP

Thank you very much for your answers. Things start to become clear now. I
have taken a JXTA summer project in my school that is why I am inquiring so
much about the JXTA implementation. If I understand correctly in my scenario
with a mobile peer if it changes its IP address and his pipe adv is still
active, the relay peer using the Endpoint protocol woud still be able to
forward messages to the peer. In the meantime, perhaps a very small
duration, if there are any messages for that peer ( it is in the process of
changing his IP address so after it abandons the "old" IP and before it
acquires the "new" one) will they be lost? Or the relay peer would continue
to try to discover a route for that peer (eventually succeeding if the pipe
adv timeout is not over and the mobile peer succesfully acquires a "new" IP
address). I am apologizing for my excessively detailed questions. I truly
appreciate your answers.

Best regards,

Giorgis Georgakoudis

----- Original Message -----
From: "Peter Fagerlund" <[email protected]>
To: <[email protected]>
Sent: Sunday, July 17, 2005 1:12 AM
Subject: Re: [JXTA discuss] NEW Re: [JXTA discuss] Mobile IP


> Generally regarding  . mobile network operators .  when switching base
> stations . your data connection stays the same . if You would switch
> mobile network operator . then You would also have a new data
> connection. ex. if You are on JXTA net with say Your laptop in a cafe
> using wifi, then move to a friends house and open your hibernated
> laptop to use friends wifi . (would equal a phone switching mobile
> network operators) .  your JXTA pipe is still there . but has not been
> active while at sleep in transport.
>
> So to try answer Your cases below consider the following :
> JXTA is IP agnostic. The PeerID and PipeID is Your JXTA presence as
> seen by the Resolver. Therefore a change of IP do not alter your JXTA
> presence. If pipe (Unicast) is not active == no bind and resolve == no
> send. Already bind and resolved pipe at device -> goes to sleep ==
> message dropped after the lease time at Relay expired. If pipe
> (Propagate) is not active == dropped.
>
> /p
>
> On 16 Jul 2005, at 22:45, Giorgos Georgakoudis wrote:
>
> > I read the paper but I did not get any clear answer. Ok, here is a
> > scenario:
> >
> > Someone is using a JXTA enabled PDA communicating in P2P JXTA network.
> > Moving in the city, the PDA's IP changes from X to Y. What happens?
> >
> > Guess 1: The Peer Advertisement that the PDA has issued still exists
> > (as the
> > timeout has not expired) so when other peers want to communicate with
> > this
> > peer they find a "new" route. There is some delay though. ( Will there
> > be
> > any missing packets granted they were routed according to the "old"
> > route?
> > Is there any caching of messages in the relay route?)
> >
> > Guess 2: The peer is considered disconnected so it issues a new Peer
> > Advertisement to manifest its existence in the JXTA universe. All
> > previous
> > communication is considered disconnected.
> >
> > Giorgis Georgakoudis
> >
> > ----- Original Message -----
> > From: "Peter Fagerlund" <[email protected]>
> > To: <[email protected]>
> > Sent: Saturday, July 16, 2005 3:14 PM
> > Subject: Re: [JXTA discuss] Mobile IP
> >
> >
> > It do not affect the jxta protocols, the mobile is recognised through a
> > jxme-proxy relay being the window in to the jxta world.
> >
> > http://www.jxta.org/project/www/docs/JXTA4J2ME.pdf
> >
> > /p
> >
> > On 16 Jul 2005, at 10:24, Giorgos Georgakoudis wrote:
> >
> >> Hello,
> >>
> >>
> >> I would like to ask what happens in jxta when we have a mobile peer
> >> that is moving through networks thus having a mobile IP address. How
> >> does that affect the jxta protocols? Is the peer considered dead and
> >> reconnected or otherwise? If there is any documentation mentioning
> >> this or any other concepts please let me know.
> >>
> >> Giorgis Georgakoudis
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]