-
Notifications
You must be signed in to change notification settings - Fork 0
Fix for send handles exhaustion #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: OOI_1.3.0
Are you sure you want to change the base?
Conversation
## [1.3.1] - 2022-12-09 ### Changes * It is now possible to set a window size of up to 64 for `ReliableSequencedPipelineStage` (use `NetworkSettings.WithReliableStageParameters` to modify the value). Doing so increases the packet header size by 4 bytes though, so the default value remains at 32. ### Fixes * Fixed an issue where if one end of a reliable pipeline stopped sending any traffic and its latest ACK message was lost, then the other end would stall. * Fixed a crash when using DTLS if an update was delayed for long enough that both the disconnection and heartbeat timeouts expire.
## [1.3.2] - 2023-03-09 ### Fixes * Fixed issue where UWP Xbox builds were crashing because the split buffer fix was not including UWP defines. * Fixed an issue where `IPCNetworkInterface` would perform useless work for each packet received. * Fixed an issue where `ReliableSequencedPipelineStage` could end up duplicating packets when sending reliable packets while the send queue is full.
## [1.3.3] - 2023-03-17 ### Fixes * Fixed an issue where calling `ScheduleFlushSend` before the socket was bound would still result in socket system calls being made, resulting in errors being logged.
…r the course of the server's life has increased
…previous approach wouldn't compile
Unity network transport layer - the low-level interface for sending UDP data
…for the issue with us running out of handles. The problem is that there was a buffer overrun which caused a Lock variable to be trashed/stomped-over. This then resulted in a section of code failing to obtain a lock and then, in that event, also failing to release the handle - so it leaked. This fix addresses the failure to release the handle in the event of this error - but, more crucially, it fixes the buffer overrun that caused it in the first place. NOTE: The final fix came from Simon @ Unity via Discord. They will be released a hotfix that we'll then want to merge, but this will be the contents of that hotfix.
| 1u, | ||
| &error); | ||
| if (error.code != ErrorCode.Success) | ||
| if (error.code != ErrorCode.Success || count != 1u) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is part of the fix. The low level Linux UDP networking code wasn't properly signaling an error (didn't end up being our issue but is a legit bug, Simon said).
| #else | ||
| return (int)Error.StatusCode.NetworkDriverParallelForErr; | ||
| #endif | ||
| driver.AbortSend(sendHandle); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the handle being released that was leaking in the event of this error.
| ReliablePacket* packet = GetReliablePacket(self, sequence); | ||
| packet->Header = header; | ||
| var offset = (ctx->DataPtrOffset + (index * ctx->DataStride)) + UnsafeUtility.SizeOf<ReliableHeader>(); | ||
| var offset = (ctx->DataPtrOffset + (index * ctx->DataStride)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the buffer overrun fix (part 1)
| header.AckedMask = reliable->ReceivedPackets.AckedMask; | ||
|
|
||
| var offset = (ctx->DataPtrOffset + ((sequence % ctx->Capacity) * ctx->DataStride)) + UnsafeUtility.SizeOf<ReliableHeader>(); | ||
| var offset = (ctx->DataPtrOffset + ((sequence % ctx->Capacity) * ctx->DataStride)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the buffer overrun fix (part 2)
After a lengthy investigation with Unity on Discord, this is the fix for the issue with us running out of handles.
The problem is that there was a buffer overrun which caused a Lock variable to be trashed/stomped-over. This then resulted in a section of code failing to obtain a lock and then, in that event, also failing to release the handle - so it leaked.
This fix addresses the failure to release the handle in the event of this error - but, more crucially, it fixes the buffer overrun that caused it in the first place.
NOTE: The final fix came from Simon @ Unity via Discord. They will be released a hotfix that we'll then want to merge, but this will be the contents of that hotfix.