Closed calvinbalke13 closed 6 years ago
This breaks reading streams because you CANNOT decide to not read all the bits in the stream pertaining to a particular code module and when further reads of the same stream are done by other code is now getting corrupted because that bit stream data doesn't belong to them.
The only way to handle this is to do whatever is necessary to generate a critical error and completely abort the stream because it's now unrecoverable. Sure you could try skipping the rest, but that oversized data chunk shouldn't have been written in the first place.
Oops, Thanks for letting me know. I need to figure out how to generate a critical error that only causes the network stream to be disconnected instead of causing Torque3D to exit. I should have a fix ready soon. Thank you for your help.
Yeah, we were talking about this in the discord. The idea is fine, but it'd be safer to have it disconnect or assert rather than just clip the stream, since that could cause a cascading issue.
I merged it because catching a theoretical buffer overrun is good and didn't run into problems, but hadn't thought about the cascading issue.
If you get a fix tossed up in the near future we can just merge that in over this, otherwise if you think it'll be a bit I can roll this back out in the meantime.
From what I chatted with my friend it is better to clear the byte buffer and reinit the connection, or alert the user there is something fishy going on with the connection between them and the provider/server.
This should be backwards compatible with existing network code, however it fixes a potential vulnerability. Please let me know if anything needs to be changed in this PR. Thanks