Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

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

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 Morxeton   Members   -  Reputation: 139


Posted 11 March 2012 - 10:53 AM

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.! Posted Image


#2 hplus0603   Moderators   -  Reputation: 6733


Posted 11 March 2012 - 02:06 PM

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.
enum Bool { True, False, FileNotFound };

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.