Omit this.
Investigate the inclusion chain of these two files. Is this include necessary?
Remove these, just a bit of immediate-mode testing here.
Return success or failure.
We can optimize here by doing the splitting at datagram creation time to create optimally sized datagrams, but it is quite more complicated, so left for later.
Check this is ok.
Convert to atomic increment, or this is a race condition.
Convert to atomic increment, or this is a race condition.
Is it possible to check beforehand if this criteria is avoided, or if we are doomed?
Check that there actually is enough space to read.
Should kill/Close the connection right here and now?
Would like to do this: FragmentedSendManager::FragmentedTransfer *transfer; { Lock<FragmentedSendManager> sends = fragmentedSends.Acquire(); transfer = sends->AllocateNewFragmentedTransfer(); }
Convert to atomic increment, or this is a race condition.
Is it possible to check beforehand if this criteria is avoided, or if we are doomed?
Log out warning if this takes AGES. Or rather, perhaps remove support for this altogether to avoid deadlocks.
Instead of waiting multiple 1msec slices, should wait for proper event.
Instead of waiting multiple 1msec slices, should wait for proper event.
Check return value.
Check return value.
This is loose, but since it only needs to be an upper bound, it is safe now.
Take into account the inOrder field.
Omit this conversion for performance.
HashTable for performance.
Loop until StopModalServer() is called.
WSACreateEvent/WSAWaitForMultipleEvents for improved responsiveness and performance.
The 4 bytes of size data are unnecessary for PODs!
Proper alignment.
Proper alignment.
1.7.1
