Skip to main content

immediate notice if peer disappears

2 replies [Last post]
henno_b
Offline
Joined: 2010-09-03
Points: 0

Hi all,
I'm using a lot of JXTA sockets, and after a long learning process it is now starting to work nicely. I have however noticed something intrigueing, and lack the in-depth knowledge to figure out what's happening here. I tried digging through the source code, but without any luck.
My question is: what might be the magic signal or event that seems to tell other peers - almost instantly - that a peer has gone off-line?
For detecting if a socket has dropped unexpectedly - e.g. somebody has pulled a network cable on the other side of the planet - the usual approach is to do a ping-like exchange, i.e. request some info and if it doesn't come within the time-out period you just assume that the line has dropped. This approach is typically invoked at the moment that you need the socket, i.e. too late. If my application would get some magic signal as soon as the line drops, a separate thread can then create a replacement socket to another peer, and this alternative line will then be available as soon as it is needed.
It really looks as if JXTA has a mysterious way of immediately notifying connected peers that a line has dropped. I saw this when I was monitoring a handfull of processes on a single computer, with JXTAsockets to each other. I killed one of the peers out of the blue, and all other windows almost immediately produced a JXTA warning message that the socket to peer so-and-so had closed. There was definitely no "clean" closeFromRemote() call, because my application doesn't have that kind of sophistication (yet). Perhaps some brave JXTA destructor manages to squeeze out a warning cry, just before dying?
I would very much like to learn how to detect this "connection gone" warning at application level. One bad way of doing it would be to scan these JXTA log messages internally in my application, filter for the one that says that the connection has dropped, and then throw an exception. This is a rather sloppy way of programming: if one day the magic JXTA log message is changed, my application won't work anymore.
Could it be that this only works on a local computer or local network, with multicast switched on? In that case it won't be possible in my application, unfortunately, because it's strictly unicast.
Thank you very much for any light on this matter....

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
adamman71
Offline
Joined: 2007-01-31
Points: 0

> My question is: what might be the magic signal or event that seems to tell other peers - almost instantly - that a peer has gone off-line?
If there is an open TCP connection between two peers, the peer remaining alive will quickly notice the 'death' of the remote peer. But, since the system has been designed to be resilient, JXTA will try other means to reconnect with the remote peer. If it comes back online, this should be successful.
> Perhaps some brave JXTA destructor manages to squeeze out a warning cry, just before dying?
If it can close the connection in time, it will, but if someone walks on the plug, no.
> I would very much like to learn how to detect this "connection gone" warning at application level.
It is not really possible, except by trying to catch any thrown exception. This is an area for improvement, I will agree. Don't try to read the logs, you're right, it is not a good idea.
> Could it be that this only works on a local computer or local network, with multicast switched on?
The answer is no. Generally speaking, there are unavoidable cases (generally rare) which cannot be handled in a 'clean' way. That is (unfortunately) life on the net and one should take it from there.

henno_b
Offline
Joined: 2010-09-03
Points: 0

Hello adamman71,
Thank you very much for your reply - you confirm what I thought, but I hoped there was something clever in these sockets that I just didn't know about. I guess we can never ever rely on "clean" remote closures. The only consistent way to decide that a remote peer has gone down will be some form of response request, with a time-out after a certain idle period. This works, but may lead to substantial delays if the time-out period is too long. Also, you can get a situation that a slow connection is misdiagnosed as a dead connection, but that is not so bad. Connections that are too slow are essentially just as useless as dead connections.
In my application, all peers work together in a rather intricate network computation process, and a delay in one peer will inevitably spread out to many others (exponentially, in fact) that depend on the particular delayed exchange. So, I try to set the time-out interval as low as possible, but have limited experience with these things on the real web. I guess experimentation is the only sensible way to find the best value.
I struggled a lot to get JXTA going, but now that I passed the big initial hurdles I start to appreciate its capabilities. I would never have managed to implement all of this myself as part of the application, so, thanks a lot for making JXTA.
Best regards
henno