Hey all, I am currently making a 2D fast-paced action-based network game. I have a working client and server and I can send messages between them. I don't have much experience making networked games but I have a Cisco CCNA 1 and 2 certification so I have some understanding on how networking works. Now I'm currently using TCP to transmit my messages, but I understand that TCP is slow and that I won't be able to use it when I start the real programming. So let's use UDP! But I also know that UDP isn't reliable. Some stuff needs reliability like shots, chat messages and the like. But player movement can be done with UDP. But here is what I don't get. Why are there debates about which one to use? Why not use both? UDP for speed critical stuff, and TCP for reliability critical stuff. I haven't tried using both yet (I can't try anything now, not on my good computer) but is it just undoable? Does it require opening two sockets? If so then I guess I can only use UDP, but how can I make reliable messages in UDP? Sorry for that wall of text, I hope you guys got what I meant. Thanks.

Quote:Original post by Xeon06
but I understand that TCP is slow and that I won't be able to use it when I start the real programming.

TCP isn't "slow". It uses same routers and same wires. But due to ordered, guaranteed delivery, if byte at time T fails to deliver, TCP will not deliver any bytes T+n until T arrives, via resend or after delay.

This is a direct consequence of such delivery. If one doesn't need guaranteed ordered delivery, or perhaps doesn't even want it, then TCP is the wrong choice in the first place.

Quote:Why not use both? UDP for speed critical stuff, and TCP for reliability critical stuff.

A recent comment.

A common reason is likely practical. Since someone using UDP needs other types of messages between completely-unreliable and completely-reliable, some form of custom reliable UDP is implemented anyway, so adding reliable/ordered packets to that is trivial and simplifies having to manage two connections.

Another reason why TCP may be undesirable out-of-box is because it performs its own bandwidth management, behavior of which may not be optimal. It depends.

Quote:Does it require opening two sockets?

Yes. Why would opening two sockets be a problem?

Quote:If so then I guess I can only use UDP, but how can I make reliable messages in UDP?

Start here.

You can do reliable communication with UDP, you would just need to do the sequencing, acknowledgement and retransmission yourself (essentially implement over UDP the things that TCP does for you). You could do these things for information that you need reliably and not do them for data where you don't.

That's how I'd do it anyway.

Thanks for the answers guy.

Opening two sockets isn't a problem, it's just annoying to have to do that, and keep track of sending and receiving messages on both for each client, in my opinion. I found this neat library (I happen to be working in C#) that does reliable UDP. I'll try using that. Thanks for the answers guys.

You can use both, if you want. However, it might be easier just to implement your own reliable control-packet layer on top of UDP and use that instead of a separate TCP connection. Like you said, if you have both, you need two sockets (on the client), and to do a little bit of extra work to synchronize them.

I'm personally using both in my current project, but it's mainly because of how I started and I wanted some practice using both. By now it's a fairly stable system that works really well, but if I had to do it from scratch again, I'd probably do UDP-only to save on the effort. I might remove the TCP connection later on if I feel it's no longer needed.

But yea, I just wanted to say it is possible and there's probably nothing extremely horrible about it. But it doesn't really offer that many advantages over UDP-only, at least nothing that can be replicated with your own custom reliable layer over UDP.

Oh, as a note, I'm using TCP to establish a connection to the server, and exchange control/info packets and stuff like chat. The UDP connection is used for all time-critical things like player movement and (in the near future) shooting.

I read that FAQ in it's entirety exactly before posting. That's where I got the link to lidgren. However, it seemed to me as UDP only by reading the description and I need reliability. It's not until this topic that I got that UDP could be reliable, too.

Quote:Original post by hplus0603
Btw: both the question of "UDP, TCP or both" and the Lidgren network library (as well as others) are mentioned in the Forum FAQ. Which is linked by the top stickied message on this board. I'm just saying you could have saved some time :-)

Please consider adding Ebenezer Enterprises to the Forum FAQ.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

Quote:Original post by Xeon06
Why are there debates about which one to use? Why not use both?

Truth be known, I think the reason there is so much debate is because there are a lot of people on the Internet with an opinion, but far fewer people with actual real world experience. It's merely a ratio, for every real developer there are 1000 more who are more interested in being 'right' than getting it right.

There is no technical reason why you can't use a TCP and UDP socket at the same time (ie. No socket library which supports TCP is ever likely to come with an api restriction like that) but as rightly pointed out already, TCP isn't exactly as friendly as UDP when it comes to NAT punchthrough, which is potentially problematic depending on your network topology. There are other relationships between TCP and UDP, like for example what happens to your TCP connection when your UDP connection is using most of your bandwidth. Though I'm sure there are plenty of people with an opinion who will explain these much better than me ;-)