Sign in to follow this  

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

This topic is 2951 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'm building up small MORPG game, which I hope that will support at least 100 players for now and I'm a bit confused between TCP / UDP selection. I know UDP is faster but not 100% on receiving packets TCP packet will reach destination for sure but it's slower. In my game, player moves tile by tyle and that's why I'm thinking about using TCP since I'm only going to send data when player starts moving, everything else will be done client side. ---------------------------- example: SEND (MOVING, DIRECTION) MOVING = 0 / 1 DIRECTION = 0 or 1 opr 2or 3 ----------------------------- The same thing goes for monsters which will move the same way and attack when they come close. Simply put, there won't be any really quick actions except some big fights where arrows/spells will fly across the world and weapons will clash... I'm really not sure if UDP is needed for that, so I want to ask you (with experience) what is the best solution. ALTERNATIVE QUESTION: Does type of protocol determinate maximum number of players that server can handle as well? Thanks!

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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 javascript. If you are interested you could try it out at http://www.furi.dk/socky

Also, if you have any network game specific questions, just drop me a PM :)

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.
But again in a turn based game (as mentioned already in this thread) it's just not needed.

Regards

/Ozak

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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/.)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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