So yea, I've used non-blocking sockets before and figured it was time to truely go with the Asynchronous sockets as they would be nicer with the message call backs. Let me make sure I have the general way it works down and feel free to correct me. I have Windows Network Programming(the end all of WinSock programming books) at home otherwise I would be consulting that but it's out of my reach currently. Server side: Listening socket gets called with WSAASyncSelect and needs to know about FD_ACCEPT. Client Socket needs to know about FD_READ and FD_WRITE and FD_CLOSE Client side: Socket needs to know about FD_CONNECT/FD_READ/FD_WRITE/FD_CLOSE The only problem I see is that on my server the clients are contained with in a linked list so the population can grow and shrink as needed. The problem with this is when a WSAASync msg is received I need to know which client caused the message. I figure I could just assign each client a unique ID(kept client side, sent on connect) and just put that ID in the header of the message. So, do I have the basic theory right? Asynchoronous sockets are pretty light on documentation so I'm just piecing together multiple sources.

Quote:Original post by hplus0603
Putting an ID in a network packet means that you can EASILY spoof being someone else, so that's not very secure. Much better to use the actual socket (for TCP), or remote network address and port (for UDP), as the key for who is who. Put the data structures per client on the server into a hash table, based on this key.

Good idea, I was reading the WinSock SDK and saw that the WPARAM of the msg loop when you recieve an Async call will give you the socket. In theory I could just use that as the Key for the hash table like you suggested and everything would be peachy, correct?

And yes, this is just a project, so security isn't my top concern but I am trying to build this library with being robust and secure in mind so I appreciate you pointing that out.

Quote:Original post by paulecoyote
More or less I think you've got it... thing is at that level you are basically creating your own protocol... and that's likely to be very specific to your application.

You didn't mention threads - you'll probably want a listening thread and a serving thread on the server side. Probably best to avoid having a single thread per client though, unless you're not expecting that many clients.

The purpose of that being to keep the listen queue as up-to-date as possible and just make the client side connect continually try to connect for xxx amount of time if it receives a blocked call?