Advertisement Jump to content
Sign in to follow this  

Design for sending/receiving over async sockets for both UDP/TCP?

This topic is 2505 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

Hi everyone,

I'm working on a networking library written in C# that I plan to use in games that I will eventually write. The library supports both UDP and TCP. I'm trying to figure out the best design for sending and receiving data over asynchronous sockets. Here's a quick overview of my current design (using new async sockets methods in .NET 3.5):

For receiving, a call is made to ReceiveFromAsync and in the callback, grab the data from the buffer and pass along the buffer and IPEndPoint over into a method which will queue it up to be read in a dedicated thread loop that will dequeue and handle each packet. ReceiveFromAsync is then called at the end of the callback.

For sending, a call is made to the "Send(Packet)" method on a custom class "SocketState" that contains the reference to the socket and end point to send to. This method will call into another method and enqueue the data in a send queue to be handled by the same dedicated thread loop that is handling receive.

Should I use a separate thread loop for sending, or am I complicating things and should just send the packet directly? I am not yet done with the implementation. I am going to be accounting for sequence numbers, ACKs, and speed control (packets per second), etc.

For receiving, as data is read from the async socket, it's passed into a method that reads the packet header info and figures out where the packet ends and next begins based on the header info of each packet (or if static packet the attributes of the packet type). Each packet is handled during the callback and not a dedicated thread loop like UDP.

For sending, the data is just sent directly and at the end of the send callback, it calls back to the send method again and checks if there is more data to be sent, and if so, continues to send data until there is nothing left in the queue.

So you can see that in UDP I am using dedicated threads for receiving, handling and sending data whereas TCP it does a lot of processing in its callbacks.

Does anyone see any problems with the design of one or both and have suggestions to make improvements? Need more information? If so, please let me know. I don't have a lot of experience with network design. I appreciate any advice/feedback/suggestions, etc.! smile.png

Share this post

Link to post
Share on other sites
I think you are approaching the problem from the wrong end. Exactly how the bits are shuffled in and out of the socket has almost no effect on your overall performance. Much more important is the higher-level questions of how data is generated to be sent, and how data is routed when received, and what that data means. Input synchronous? State replicated? Forward extrapolated? Interpolated? Smoothed? Entities with properties? Game-specific control data? Do entities enqueue packets of data, or just requests to generate updates from objects at the last minute? These things matter, and will also somewhat decide which API mechanism makes the most sense.

The amount of I/O on the sockets is going to be minuscule; you could poll from the main thread and it would be OK for up to something like a hundred clients.

If the question really is one of "how do I use .NET APIs correctly" then you probably want to use a thread pool for all your asynchronous operations, and then have some kind of lightweight mailbox system to pitch received data into the game, and generated data into the I/O pool.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!