Reliable Message Delivery - JxtaBiDiPipes

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?

Thanks,

Paul Poole
Software Engineer
Lockheed Martin