Usage constraints

Intricacies when using JNetRobust:

• Sender and receiver must send data at a fixed rate to each other
  • Both must send at the same rate for the congestion control to work
  • Rate can be as slow as needed, but must not be faster than 120Hz (every ~8ms)
• Communication may be unidirectional, in which case the receiver must respond with empty, acknowledgement-only packets
• Broadcast / multicast is not supported
• Network conditions of the underlying communication medium may be dire
  • RTT jitter must be lower than 250ms when sending at 120Hz (useExtendedAckVector option must be enabled)
  • RTT delay irrelevant, as long as it's within +/- jitter
  • Put differently, the delay between receiving the acknowledgement of two consecutively sent packets must not be greater than 500ms when sending at 120Hz (useExtendedAckVector option must be enabled)
  • Packet duplication chance is irrelevant
  • Packet loss chance must not be too extreme in order for the data to be delivered reliably and in-order
    • (Synthetic) tests show 10% loss chance is ok (may be more)
    • Real-life loss chance is typically 10e-6% for wired, or up to 1% for lossy (wireless) connections
  • If the network conditions are more extreme than described, exceptional listener methods will be invoked to inform user about it, after which protocol will re-establish reliability and ordering starting from newer data

tl;dr

This library has been developed primarily for applications that need (reliable,) periodic updates (e.g. games, where actions or state need to by synchronized across other hosts at fixed intervals).
It's thus not suited for streaming data or media reliably with highest throughput.