I explained some of the net code here, but it was mainly stuff related after:
So, The e variation is pure winsock event implementation and the non-e versions uses iocp handles and winsock. Thats why there's a windows version check for what version to run.
Your dpscock class is a transparent layer for what it manages. Ie: CServerSock, or CCLientSock. CSock just stores the SOCKET and etc (socket::native_handle in asio terms).
The DPMng class is your "direct play manage" class, direct play being an old directx9 framework idea, that they dont even really use fully. This class is supposed to handle receiving the messages or dispatching messages back. (hence the __TEST_SERVER_ENCR or whatever define you sometimes see in sources overriding the send function with a xor encryption).
Sending is very simple, it transmits the data to the server.
Receiving on the other hand is a bit more complicated because DPMng handles the reception buffers, but not the actual retrieval process.
Hey There!
Please login and(or) register to see this awesome content today.
And then within the fetch function (which is a bit too long so ill avoid posting)
But, what could fix this issue?
1. Make the buffer and bufferqueue class safer. (and limit the size of a buffer)
2. Unify the transmission protocol code for all servers, and then properly use it. (IE: so you can make a crc based connection on any server if needed but the idea is to unify the code because the fetch function is essentially doing fetch for both protocols which is definitely causing some mishap here.
3. Avoid setting net errors on the server, handle error and continue, disconnect sender.
4. headermark is also a thing
