Definition
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
| Name | Description |
|---|---|
| frag_size | The max number of bytes in a message. Larger messages will be fragmented. Default is 8192 bytes |
| id | Give the protocol a different ID if needed so we can have multiple instances of it in the same stack |
| level | Sets the logger level (see javadocs) |
| max_retained_buffer | The max size in bytes for the byte array output buffer |
| name | Give the protocol a different name if needed so we can have multiple instances of it in the same stack |
| stats | Determines 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.
Comments