RE: Reliable Message Delivery - JxtaBiDiPipes

I seem to recall reading that the relay had that capability.  However,
wouldn't it be required that you would need to force the usage of a
relay (assuming the other node isn't behind a firewall)?  If this isn't
default behavior (that is, to use a relay) or if there are only 2 nodes
on a jxta network, then this solution is going to solve my problem. 
 
I need to dig into the jxta code a little, but my thoughts are that if
the bidipipe detects a loss of connectivity, couldn't the messages be
queued until the recipient rejoins or a specified timeout occurs?
Perhaps this is best left at the application level rather than the
protocol level.
 
Are there any other ideas?  Your thoughts are very much appreciated.
 
Thanks,
 
Paul

	-----Original Message-----
	From: Vanessa Williams [mailto:[email protected]] 
	Sent: Thursday, August 11, 2005 10:57 AM
	To: [email protected]
	Subject: Re: [JXTA user] Reliable Message Delivery -
JxtaBiDiPipes
	
	

	On 10-Aug-05, at 2:43 PM, Poole, Paul P1 wrote:


		Hi all: 

		As my previous posts might suggest, I am very interested
in reliable communication with MyJXTA.  In my build of JXTA, I have set
JxtaBiDiPipe communication to default to reliable (e.g. isReliable =
true).  With this build, I have setup an isolated environment consisting
of only 2 nodes (laptops).  As a test of the reliability of these pipes,
I did the following:

		        1. Fired up MyJxta on laptop (node) 1 
		        2. Set node 1 as a rdv 
		        3. Fired up MyJxta on laptop (node) 2 
		            Note: both nodes see each other fine 
		        4. Initiate a "chat with peer" from node 1 (rdv)
to node 2 
		            Note: a test shows that the one-on-one chat
is working correctly for both nodes 
		        5. Remove node 2 from the network (I simply
unplugged the ethernet cable) 
		        6. Send a sequence of messages from nodes 1 and
2 

		At this point in the test, after a few messages are sent
(within 10 - 15 seconds), both node's MyJXTA windows stop responding.
It is as if when it detects that the linkage has been broken, a blocking
occurs.  Upon reconnection of the ethernet cable (after about 20 - 30
seconds) the two nodes start responding again and can communicate.
Importantly, not all of the messages sent from the two nodes reach their
destination... some messages are lost and those that are received are
not necessarily in order (this goes for both nodes).

		Interestingly, if I perform this exact test with the
JxtaBiDiPipe's isReliable set to false, then the two nodes do NOT stop
responding AND ALL of the messages are received for both nodes (for
these tests, the node was removed from the network for about 45 - 55
seconds).  However, the order is not always correct.

		Is this an expected result?  If not, can someone
reproduce these results? 

		What I would consider ideal is when a node leaves for a
BRIEF period of time, messages will be queued by the senders (by this I
mean messages sent by the node that left and the one that stayed) until
the node returns.  

		My next test will be to add a third node, which will be
the rdv and can act as a liaison.  

		Any thoughts?


	I believe if you use a relay between the peers, the relay will
store and forward messages on behalf of briefly disconnected clients.

	Vanessa



		

		Thanks, 

		Paul Poole 
		Software Engineer 
		Lockheed Martin