RE: Reliable Message Delivery - JxtaBiDiPipes

Thanks Vanessa.  I agree about the reliability factor with two nodes :-)
I will look into the relay option more closely.  I may also try to
implement some type of queueing feature and see what provides me with
the best solution.  Anything worth noting, I will report back to the
list.
 
Thanks for your help.

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

	On 11-Aug-05, at 11:26 AM, Poole, Paul P1 wrote:


		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.
		 


	From what I can see, JxtaBiDiPipe uses the same reliability
layer as JxtaSockets. Messages will be retransmitted if lost, but
tweaking the timeout parameter might be tricky. It works in theory, but
may not be as tolerant as you'd like. You could try upping the timeout
(when creating the JxtaBiDiPipe) past 60 seconds and see what happens.
The timeout is probably meant to be kept quite low, though, so cranking
it up to a few minutes' time would not be a great idea. For transience
more coarse-grained than that, I think a relay is the only way to go.
AFAIK edge peers can be easily auto configured to use a relay. If there
are only two nodes, and one of them can't be a relay, then this won't
solve your problem, it's true. On the other hand, how much reliability
can one expect from a network with only two (non-super) nodes...?

	hth,

	Vanessa


		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