Sign in to follow this  

Fumbling through Async Sockets.

This topic is 4861 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

This topic is 4861 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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

Sign in to follow this