Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-2566

Remove need for flow control, retransmission, fragmentation on selected transports

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Major Major
    • 5.5
    • None
    • None
    • False
    • False
    • undefined

      When running over TCP or TCP_NIO2 transports, which use TCP/IP for flow control, retransmission and fragmentation, JGroups' own protocols such as UFC/MFC (flow control), NAKACK2/STABLE//UNICAST3 (retransmission) and FRAGX (fragmentation) can be removed, to take advantage of TCP/IP's functionality.

      We can also remove only unicast functionality (UNICAST3, UFC) or multicast functionality (NAKACK2, MFC, STABLE), or both.

      TCP/IP's functionality has been refined over decades, and JGroups does not need to duplicate it. So flow control, fragmentation and retransmission would only be provided over UDP, which doesn't have this functionality.

      However, there are a few caveats:

      • Multicast (= one-to-many, NAKACK2) messages still need to be numbered (sequence number), as the thread pool on the receiver side might reorder them. Delivering messages in order of seqnos ensures ordered delivery. NAKACK2 can be dropped altogether when a single sender bundler is used (see below)
      • Unicast messages: UNICAST3 can be dropped altogether
      • In both cases, retransmission would be disabled: messages would only be added a seqno when being sent, and they would get delivered in order of seqnos. Message retransmissions and/or acking is not needed, as this is done by TCP. Investigate if we can remove NAKACK2/UNICAST3 altogether!
      • TCP/IP considers a message delivered when it is handed over to JGroups. This means, JGroups must not drop a message, e.g.:
        • The thread pool cannot drop a message when full. Use CallerRunsPolicy, for example, or use a special rejection policy
        • Protocols, such as RED cannot be used
        • A bundler, which drops messages when full, cannot be used, either
        • For multicast messages, when NAKACK2 is not present, bundlers which don't result in 1 thread sending (such as NoBundler), might destroy ordering:
          • Message to B,C,D: Thread-1 sends M1 to B,C, then pauses
          • Thread-2 sends M2 to B,C,D
          • Thread-1 sends M1 to D -> this results in D receiving M1 and M2 in an order that's different from B and C
        • If NAKACK2 is still needed (e.g. when using NoBundler), then we could disable retransmission (by setting xmit_interval to 0)
      • If we remove NAKACK2 altogether, then state transfer won't be possible, as we won't have access to digests!

              rhn-engineering-bban Bela Ban
              rhn-engineering-bban Bela Ban
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: