Usage of UNICAST3, NAKACK2 and FRAG3 with TCP transport

[alon3392]

Infinispan's has default JGroups configuraiton for TCP (https://github.com/infinispan/infinispan/blob/master/core/src/main/resources/default-configs/default-jgroups-tcp.xml). Infinispan Server is also based on this configuration when TCP transport is selected (default is UDP).

TCP transport is recommended in the User Guide for clusters under 100 nodes when distributed caches are used.

My question is about some of these protocols configured when TCP transport is used.

- UNICAST3 and NAKACK2 are used to implement retransmission and message ordering for messages.

This is needed when UDP transport is used, but with TCP is it really needed and what is its behavior when used with TCP?

- FRAG3 does fragmentation and reassembly of messages. Same as with the previous item, is it really needed with TCP and what is its behavior when used with TCP?

Thanks.

[belaban]

While TCP/IP takes care of lossless and ordered sending of messages, they can still get reordered on the receiver side by the thread pool sending up received messages concurrently. UNICAST3 makes sure that unicast messages are delivered in per sender FIFO order. See [1] for details.

FRAG3 creates messages fragments that are never bigger than the max_credits size in MFC/UFC and the max_bundle_size in the transport. *If* you set max_bundle_size to the largest message you ever send, remove UFC and FRAG3 and have TCP as transport, then that might probablywork as well... However, as messages are stored in retransmission tables, which are purged only when all members have received them, it is probably better to have smaller-sized messages. Granted, not really relevant for unicast messages.

[1] Reliable group communication with JGroups

[alon3392]

Thanks for the answer.

So for TCP would it be possible to have ordering of messages without paying additional overhead of acks produced by UNICAST3 that are used to implement lossless transport?