Closed acmcarther closed 7 years ago
I'm curious, is there something special about 8K vs 1K? Seems like Ethernet MTU is 1500bytes, so anything about that is going to get fragmented anyways, but that's at the UDP/TCP level.
@hestela I figured a packet larger than 8kb was inconceivable, so I set the limit at that. I don't have any familiarity with the net stack below the surface of UDP.
Do you happen to know what a fragmented packet (over 1500bytes, as you suggest) looks like on the receiver's end? Does it literally split the payload into N fragments?
Yes it quietly gets split up and reassembled on the receiver end, only way you would notice is if you used wireshark and saw a larger than expected amount of packets for a specific data transfer. TCP has built in logic to probe the network to find the optimal packet size, you can take a look at https://en.wikipedia.org/wiki/Path_MTU_Discovery if you are interested. Probably the easiest way to decide would be to have a simple bandwidth test run for say 20 seconds or so and then play with the max size. I have seen peopleonline say TCP has many optimizations to improve network utilization.
or you could do 64K and let the low level UDP do the extra work
The intended use case for this library is for high volume unordered traffic. Specifically, game state is going to be sent down these channels at a pretty high rate, between 10 and 30 times a second.
Glossing over the packet size restrictions is probably a bad precedent to set, though it doesn't really matter since I'm the one writing code on top of this.
That does remind me though. I need to get a sense for the supported throughput and where the hotspots are. #9 created
hestela@ I updated the buffer size to equal my calculated MTU.
Its NBD if its not super accurate -- whats important is to enforce some maximum payload size.
This stops gaffer_udp from padding packets up to 1024, and also allows it to support packet sized up to 8kb.
@wmedrano @hestela
pls rev