Re: 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
>