Sign in to follow this  
  • entries
    557
  • comments
    1237
  • views
    421594

Sodding IO COmpletion Ports...

Sign in to follow this  
Evil Steve

98 views

I've been having a lot of issues with IO completion ports for TEH MORPG!!1. I seem to remember having these exact problems the last time I tried, so there might be something I'm mis-understanding.
An example of a problem I'm having is that connect() doesn't want to work properly. I use WSAEventSelect() to get notification when the connect is complete, and I have a thread that only handles new client and connect complete notifications. However, I quite often never get the connect complete notification (the event is never signalled). This might be unrelated to the IOCP of course.

Another thing is I have all sorts of issues when a client disconnects. If the server kills the connection, then it tends to send data, then Release() the CSocket. Release() frees the socket descriptor with closesocket() and clears any buffers. That however, causes the IOCP to spaz out, since the socket was ripped out from under it. Then the write event goes through, and I have to check that the socket hasn't already been freed, which is horrible.
What I think I need is some sort of pool of "dead" sockets, and when CSocket::Release() is called, the socket is added to the pool, and the IO is cancelled (not sure how to do that though). When the IO cancel event is picked up by a worker thread, the socket can be removed from the dead pool and properly destroyed.

Whether that'll work or not is anyones guess. This code is turning into a bit of a mess, mainly because CSocket and CSocketManager are friends of each other. I might make an interface to CSocketManager that's only availiable to CSocket, that'd probably tidy things up and make syncronisation easier.

I was also reading about a lock free free list implementation in Game Programming Gems 6, on the train this morning. I really don't understand how it works, but it looks perfect for my uses. I already have 3 free lists for storing a list of overlapped structures for IOCP, sockets, and something else I forget at the moment. All of them need synchronised, since all of them are accessed from all threads. "All threads" being the main thread, the accept()/connect() thread, and the numProcessors*2 worker threads - making a total of 6 threads in my case, and that's just for the socket manager...


In other news, we got into the building 15 mins late this morning, because we only have one set of keys, and the one person with them was late this morning. We can't get another set cut because nobody can pay for them, because we don't have an office manager yet. Fun.

Anyway, back to work...
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now