Version 5



    Fragments messages larger than 'frag_size' bytes. Unfragments at the receiver's side. Works for both unicast and multicast messages.


    Compared to FRAG, this protocol does not need to serialize the message in order to break it into smaller fragments: it looks only at the message's buffer, which is a byte{FOOTNOTE DEF  } array anyway. We assume that the size addition for headers and src and dest address is minimal when the transport finally has to serialize the message, so we add a constant (by default 200 bytes).  Because of the efficiency gained by not having to serialize the message just to determine its size, FRAG2 is generally recommended over FRAG.


    Configuration Example


         <FRAG2 frag_size="8192" down_thread="false" up_thread="false"></FRAG2>


    Configuration Parameters

    frag_sizeThe max number of bytes in a message. Larger messages will be fragmented. Default is 8192 bytes
    idGive the protocol a different ID if needed so we can have multiple instances of it in the same stack
    levelSets the logger level (see javadocs)
    max_retained_bufferThe max size in bytes for the byte array output buffer
    nameGive the protocol a different name if needed so we can have multiple instances of it in the same stack
    statsDetermines whether to collect statistics (and expose them via JMX). Default is true


    See also Protocol Configuration Common Parameters.


    I sometimes see FRAG or FRAG2 in a TCP- or TCP_NIO-based config.  Why is it there? Doesn't TCP already provide fragmentation?


    TCP does provide fragmentation, but a fragmentation protocol is still needed if FC is used. The reason for this is that if you send a message larger than FC.max_bytes, FC.down() would block! So FRAG2.frag_size needs to be set to always be less than FC.max_bytes.


    For an explanation of why you'd have FC in a TCP- or TCP_NIO-based config, see the FC page.


    Back To JGroups