Need help for game (TCP or UDP) - I've read FAQ

TCP can be used for the vast amount of MMOGs, the only time you really need to look at UDP is if you are doing something more immediate fps-like or more realistic physical simulations. You described moving tile by tile which is actually what Ultima Online did and that uses TCP... also note other small games that use TCP such as World of Warcraft :)

Thanks a lot for your answer, that helps me a lot :)

But, let me correct if I'm wrong, doesn't WoW uses UDP and TCP mixed?

Hi. I'm new to these forums but I've been working as a pro game developer for almost 14 years (Including 3 mmo's)

You should definitely go with TCP/IP.
Using a simple string based protocol is a good solution.
You might want to encrypt the transfer later for safety, but for now it should be fine. Remember to put all validation on the server. Never trust the client :)
But again. That's advanced stuff. Just get your game up and running and you can worry about the other stuff later.

Funny enough I did a free java crossplatform TCP/IP server that can be scripted in &#106avascript. If you are interested you could try it out at http://www.furi.dk/socky<br><br>Also, if you have any network game specific questions, just drop me a PM :)<br><br>With regards to WoW they might use UDP for quick movement, but you are better off to implement some kind of interpolation as it saves bandwidth. <br>But again in a turn based game (as mentioned already in this thread) it's just not needed. <br><br>Regards<br><br>/Ozak

Quote:

Original post by Blodyavenger Thanks a lot for your answer, that helps me a lot :) But, let me correct if I'm wrong, doesn't WoW uses UDP and TCP mixed?

I'm pretty confident that WoW uses only TCP.

To elaborate a bit. It's my opinion that UDP is simply not needed. Even for action games.

You are going to need some kind of movement interpolation/prediction anyway if you are doing an action game.

This will also ease the load on the server/bandwidth :)

/Ozak

Ozak, as I can see, you've been working in game design for a long years so I take your suggestion for granted so I'm going to use TCP/IP protocol. Thanks a lot for the answer and future service (I'm sure I'll need help along the way)

I completely agree with Ozak on the protocol to use. I've just gotten our TCP client/server modules working about a week ago. Watch your architecture and make sure it is simple.

I went through 3 iterations of architecture only to realize that I had too many abstracted layers which really slow everything down. I would also recommend that you stick to using the base Socket class, not TcpClient/TcpListener. Those are classes that inherit the Socket class and while you can have a high-performance server using them, it is yet another class that takes up resources.

Finally, my last piece of advice is to, at the very least, use asynchronous processes on the server. I would recommend using the same async processes on the client as well. Using async will reduce thread implementation on your part as async automatically threads at the system level (and therefore much more reliable - so they say...).

At this point, our server is nearly 100% free of anything event driven. And, we will be implementing async UDP processes. With the product we are developing, we simply want to provide the game dev the option of using TCP or UDP as both have their uses. UDP could be useful for the mundane chat messaging between players.

Have fun and don't hesitate to PM me if you have any questions.

One thing I forgot to mention using TCP. I believe the maximum packet size is 1500 bytes, although you can set your buffers higher. I set my buffers to a default of 1024 bytes. Because the client/server will queue outbound data, I can check the byte size of outbound messages to try and fill the entire 1024 bytes.

Yes, TCP may be a little slower than UDP, but, if you take advantage of your buffer and fill it, then the appearance of being slower will greatly diminish.

not sure what you mean about that. Is that to circumvent the Nagle algorithm (TCP_NODELAY)?

Because the actual MTU has no direct impact on TCP (or UDP for that matter). A single UDP datagram can be up to 64K in size (although I never could get a datagram bigger than the single MTU on a 360), for a TCP stream, it just wont matter as the stream will be broken down into smaller packets.

What will be important is the allocated input and output buffers for your socket (by default, it's only 16K on a 360, ouch!). iirc, it's 64K as well. If you send too much too fast, the buffer will 'clog up', and your send will fail. If you don't poll the socket fast enough, your receive buffer will also fill up.

In either case with TCP, the consequences are not terminal, and you can recover from that relatively easily.

And also reducing the Nagle buffer to something smaller, or as ddboarm says have a 'flush()' function that will fill up some padding data so that the packet is forcibly sent.

Nagle isn't your only problem with TCP - you also have the issue of delayed ACKs. In my experience the safest way to guarantee low latency with TCP is to keep the stream flowing, steady and regular.

(Good reading to be had here: http://www.stuartcheshire.org/papers/NagleDelayedAck/.)

Another option for TCP is to simply open two connections, and keep them both flowing. Send packets on alternate connections. If one has an occasional drop, at least half of the packets will still get through without delay. Generally, though, this is overkill -- for RPG-type games, TCP is quite good enough.
Also, UDP based protocols have problems where they may lead to catastrophic failure when trying to scale up -- TCP is carefully designed to throttle back so it doesn't make things worse when routers get congested. Building that into your own UDP protocol is a lot of work, and something that most game protocol tutorials don't deal with.