So far, the UNICAST protocol was not strictly necessary over TCP,

because TCP does retransmission and ordering itself. However, with a

thread pool delivering unicast messages in the transport, there was a

chance that TCP messages got delivered to the application out of order

{FOOTNOTE DEF 1 1}.

So, in recent versions, we added UNICAST to all TCP-based configurations.

This takes care of ordering. However, UNICAST still performs

retransmission, although this is not necessary, as TCP does this for us.

In 2.6 (and CVS head, 2.7), I added a flag xmit_off (default: false) to

UNICAST {FOOTNOTE DEF 2 2}. If set to true, retransmission is NOT performed by UNICAST,

but we instead rely on the transport to do retransmission. Note that

this only works with TCP as transport. Do NOT use it over an unreliable

transport like UDP !

I changed all configs shipped with JGroups to set UNICAST.xmit_off to

true in TCP based config.

This will be in 2.6.3.CR2 and GA, it is NOT in CR1 or previous releases.

Update: it turns out we couldn't implement xmit_off, for the reasons outlined in JGRP-717 (below).

{FOOTNOTE DEF 1 1} http://jira.jboss.com/jira/browse/JGRP-716

{FOOTNOTE DEF 2 2} http://jira.jboss.com/jira/browse/JGRP-717