Sign in to follow this  

Should I use TCP/UDP/SCTP?

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

I have two applications (basically, a client and a server) which is essentially a means to access a remote database. This isn't the only use, but it is the main use. The client sends requests in the form of binary-serialised messages, and the server sends the responses back in the same way. I'm currently using TCP to handle the exchange of data and am wondering if UDP (augmented with some extra reliability) or perhaps another protocol (SCTP?) might be a good option. Reliability is paramount - if the client sends a request, I need to get a response. Ordered messages are less important - if there is a blip and request #213 gets there before #212 then no problem. Duplicated packets isn't a problem either, as I already use a unique 'request ID' for all my requests anyway. Integrity of packets, as I understand it, is essentially guaranteed for both TCP and UDP. Basically, I want to know if adding reliability to UDP is a waste of time. It seems as though I'd only end up with a (probably less efficient) TCP-style protocol. As mentioned above, I'm also thinking of giving SCTP a go. That said, I'm using .NET and SCTP isn't even implemented which leads me to believe, perhaps naively, that SCTP isn't sure a big deal either?

Share this post


Link to post
Share on other sites
How big are these messages? I have no experience with SCTP first-hand, but it seems it is more for streaming large sets of data, especially when you want to make sure the stream doesn't die just because one server goes offline, or for easier implementing of load-balancing.

Only reasons I could really see you wanting UDP over TCP is that if you need to support a ton of clients or lower latency. It may be worth it if latency really matters (such as real-time collaboration with multiple users at once, though even that would be questionable), or if you are serving quick and small requests from tens-of-thousands of clients at once (UDP will shine here due to being connectionless).

For the most part, sounds like a lot of work for very little, if any, gain. But if you really do want to try it out, I suggest using an existing library that supports reliable UDP instead of writing your own.

Share this post


Link to post
Share on other sites
The requests are always small (often under 100 bytes since they are binary-encoded), the responses are variable-length but probably average at a few kilobytes.

Tons of clients is likely, but not tends of thousands - there will likely be hundreds at once. Latency is something I'd like to keep as low as possible. They will be quick and small requests ideally, but the connection itself would be maintained throughout the session so I don't think the connection-oriented nature of TCP will slow things down too much.

I'm still undecided, but perhaps I'll have a play with wrapping a custom protocol around UDP if only as a learning experience.

Thanks for your reply. Any other advice would be welcome. :)

Share this post


Link to post
Share on other sites
It sounds to me as if TCP is the best option for you.

UDP should be used when the latency of delivering any one packet is more important than any reliability metric. Positions of entities in fast-paced games is one such class of data. However, transactional operations are not, unless they somehow are very, very latency sensitive.

Share this post


Link to post
Share on other sites

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