<div dir="ltr">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.<div>
<br></div><div>ENetHost has two new fields: maximumWaitingData and maximumPacketSize.</div><div><br></div><div>To change either of these, all you have to do is write your new value into these fields and you are done.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Just a heads-up so that large packet users don't get bit by the change in behavior.</div><div><br></div></div>