Hi! Up until now, my MMORPG (Very early development stage) has been using the transmission control protocol (TCP) for data transfers. The reason that I've used it is that I like TCP much more than UDP, and I just didn't want to deal with the problems of UDP. (Packet loss, etc) I'm not sure if I want to switch really, but I just feel I have to ask, to make sure I don't destroy it all by sticking to TCP: Is it *possible* to run a MMORPG with the TCP protocol? By possible I mean "will it host more than like 100 players". Thanks in advance! - Martin a.k.a Aire.

Yes its possible, especially with a typical RPG. A much more action focused game might suffer if it's relying on TCP only.

Also note that we're talking about a 3D mmorpg here so there's a lot of data being sent and received.

Uh yeah, and one more thing, the server is muti-threaded. It spawns one thread per connection. My friend said this is likely to choke the server? Any alternative methods?

EDIT:
@Rebooted: Thanks for the fast reply!

Quote:

Original post by Aire Is it *possible* to run a MMORPG with the TCP protocol? By possible I mean "will it host more than like 100 players".

That depends if you call World of Warcraft, Guild Wars, Ultima Online, and many others playable... all of which use TCP.

If your server is built to run on Windows than you definately want to be using IOCP and asynchronous calls so I would seriously look into that.

Dark Age of Camelot also uses TCP. It has a UDP channel, but will work without it if you block the UDP packets when the client starts by sending the packets it would have sent over UDP over the TCP connection.

Saruman: The server is developed on Windows but the platform it'll be running on is Linux.

Quote:

Original post by Aire Uh yeah, and one more thing, the server is muti-threaded. It spawns one thread per connection. My friend said this is likely to choke the server? Any alternative methods?

With 100 active threads you're not gonna enjoy the performance. Look into select(). It's not necessarily the best performing solution, but it scales to 100 players far better than threads would.

Yeah, I know select(). I thought of a model where one thread would read user input and accept connections, and one would parse the messages and send replies. Would that work?

100 TCP sockets is likely not going to be a problem.

100 threads would be cause for concern.

1 thread for reading data and putting in a queue, and 1 thread for processing queue would work, although would likely not offer any noticeable performance advantage over a single-threaded approach, even on a multi-CPU machine.

Quote:

Original post by hplus0603 1 thread for reading data and putting in a queue, and 1 thread for processing queue would work, although would likely not offer any noticeable performance advantage over a single-threaded approach, even on a multi-CPU machine.

particularly because that is almost exactly what the os is doing for you to let you use select()