Re: [jgroups-dev] Does UDP support positive acks?

On 5/25/11 6:42 PM, Dan Noguerol wrote:
> Hi all,
>
> I'm developing an Android application that uses JGroups for peer-to-peer eventing. My requirements are very similar to TCP in that I require immediate and guaranteed delivery of messages in the order sent. Basically, updating a GUI element on one device needs to propagate to all other devices as quickly and reliably as possible.


OK


> It would be really nice to keep things connectionless (for several reasons) and use UDP but I've only seen a way to do negative acknowledgements. This has the unfortunate effect of not
>detecting missed messages until a subsequent message is received and the 
gap is discovered.

Correct, the 'last message missing' problem [1]. In practice, this is 
very rare. I've only seen it happen with bursty traffic and smallish 
network buffers (switch, IP queues).

This is handled by STABLE; with every STABLE message, we're sending the 
highest message received per member, so everybody sees whether they have 
the lastest message from P. If not, they'll ask P for retransmission.

STABLE runs (1) every N bytes or (2) every M milliseconds. It can be 
kicked off programmatically or via probe.sh:

probe.sh op=STABLE.runMessageGarbageCollection


Programmatically (on every node):

JChannel ch;
STABLE stable=(STABLE)ch.getProtocolStack().findProtocol(STABLE.class);
stable.runMessageGarbageCollection();


> Events in my application are fairly infrequent (one every couple of minutes) so this is unacceptable. Is there a way to do positive acknowledgements with UDP in JGroups?


No. There used to be one (SMACK), but I removed it in 3.0 (or 2.12 ?). 
In my view it doesn't make sense to have the overhead of acks for 
point-to-multipoint communication, especially for larger clusters.


> For now, I've been running with TCP but am seeing some reliability issues with it. I'm debating whether to start debugging the TCP issues or figure out a way to use UDP.


While I don't know your app, TCP doesn't scale well to larger clusters, 
as every message M is sent N-1 times (N = cluster size). Plus, discovery 
has to either be static (a list of members) or use an external lookup 
service.


> Any thoughts or suggestions would be very helpful.

I seem to remember that Yann mentioned IP multicasting issues on Android 
<= 2.2 (supposedly fixed in 2.3). That's why I wrote BPING, which is a 
simple discovery protocol based on broadcasting. Contact him directly 
for details, the blog post [2] should give you his address.

Another thing you could try is blocking RPCs for event delivery. If you 
have 5 nodes, the caller will block until 5 responses have been 
received, or a timeout kicks in. If the timeout kicked in, then you 
could investigate which nodes didn't send a response and possibly send 
another RPC to 'flush' a missing RPC out. Here, a response is a sort of 
ack.  Not really nice though. Again, the last message missing issue 
should be very rare.


[1] 
https://github.com/belaban/JGroups/blob/master/doc/design/varia2.txt, 
"Last message dropped in NAKACK"
[2] http://belaban.blogspot.com/2011/01/jgroups-on-android-phones.html

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Javagroups-development mailing list