[ENet-discuss] Warning: Maximum packet size and packet backlog limits

[Lee Salzman]

In an effort to deal with certain malicious attacks on ENet servers, I have
instituted some more strict packet limits in the github repo. I am just
sending out this notice because this change may negatively affect some
current ENet use-cases unless the developer is aware of what the limits are
and how to change them. These changes will be effective in the upcoming
ENet release (1.3.12), which should happen soon.

ENetHost has two new fields: maximumWaitingData and maximumPacketSize.

To change either of these, all you have to do is write your new value into
these fields and you are done.

maximumPacketSize both forbids packets from being received and sent if they
are larger. The default setting for this is now 32MB, beware. Set this
higher if you need it higher and are sending gigantic individual packets.

maximumWaitingData is a bit trickier. It is the maximum amount of total
waiting data that may be sitting in any single peer's receive queue
undelivered. The default is 32MB. So if you have 32MB total of packets
sitting in a peer's receive queue, no further packets will be accepted onto
that peer until you start receiving them.

Note that the effective limit on the amount of queued data on a peer is
actually maximumWaitingData + maximumPacketSize-1 due to the interaction
between these two variables. Rather, that if there is at least one byte of
available space in the receive queue for the peer, ENet will allow a packet
of up to maximumPacketSize to be received still, in an effort to prevent
smaller packets starving receipt of larger packets.

If in doubt, just set maximumWaitingData to a value equal to or greater
than maximumPacketSize if you change maximumPacketSize. However, this need
not be the case, as explained in the above paragraph, and
maximumWaitingData should be treated as a sane limit to the amount of data
you want sitting in a peer's backlog, with the understanding it can be
momentarily exceeded by maximumPacketSize.

Just a heads-up so that large packet users don't get bit by the change in
behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20140416/81b1d3a4/attachment.html>