Only panic when sending large packets if in debug mode #87
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What it says on the tin.
I also moved the packet size checking to the UDP socket layer, since technically the thresholds will be different for different network transports.
Also, the original panic-always behavior is super annoying when you tell ggrs your input type is "arbitrary buffer of bytes" and rely on the delta (XOR + run length) encoding to shrink it down, because if your "real" input type has e.g. optional or variable sized data in it (like a vec of positions, or similar), then the delta encoding won't shrink the message below the packet size cut-off - and then on high latency connections with long send queues ggrs will crash.
(That issue could also be improved somewhat by improving the delta encoding: currently delta encoding encodes xors each input against the last confirmed input, but I think it should be possible to delta encode against the last confirmed input N for the input N+1, then for N+2 encode vs N+1, N+3 encodes vs N+2, etc - and ideally factor in custom input prediction too. But that's much more involved than this PR!)
In my personal fork of ggrs, I have actually added logging and I think that's the better approach, but that's a relatively invasive change - so I stuck with the conservative approach here.