You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If an addon developer injects a chunk in the outgoing packet event, the chunk will appear in the next of outgoing packet. This causes 400~500ms of latency and makes some order-dependent usages impossible.
It should instead be appended to the current outgoing packet buffer.
This, of course, implies that overflows need to be handled. Order of packets can be important, so overflow handling would need to maintain the order and not (for instance) get appended to the end of the subsequent packet. As far as how important it is to properly handle overflows, my memory is that the outgoing packet buffer is almost never filled up, but that gearswap pushes users a lot closer than they could possibly get on their own. I think we did the math and 2 big equipset + action + standard outgoing client packet gets pretty close to full.
The text was updated successfully, but these errors were encountered:
If an addon developer injects a chunk in the outgoing packet event, the chunk will appear in the next of outgoing packet. This causes 400~500ms of latency and makes some order-dependent usages impossible.
It should instead be appended to the current outgoing packet buffer.
This, of course, implies that overflows need to be handled. Order of packets can be important, so overflow handling would need to maintain the order and not (for instance) get appended to the end of the subsequent packet. As far as how important it is to properly handle overflows, my memory is that the outgoing packet buffer is almost never filled up, but that gearswap pushes users a lot closer than they could possibly get on their own. I think we did the math and 2 big equipset + action + standard outgoing client packet gets pretty close to full.
The text was updated successfully, but these errors were encountered: