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?

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.

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. :)

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.