server-client, threads

[Godsend72]

Hello, i have a few questions.

I have created a TCP server with socket selector and it supports multiple clients.
The game would be multiplayer only, 10 clients max.

-The question is should i make that the server runs the simulation and checks collision and then it
    sends positions/moving direction to clients, and the clients sends moving directions and when they preform some action like shoot jump?

-One more thing, what part should be in another thread on server and on a client?
    I tought about creating one thread for sending and one for receiving, both for server and client.

-PS. is there any difference between sending packets and char array?
    Currently i am sending a char[] and it works ok, but i think packets would be a lot simpler.

[Jesper Juhl]

Yes, there is a difference between sending a sf::Packet and a char array - otherwise, why would Packet exist? Check the implementation for the details.

Whether you do collision checks (and whatnot) on the server or client side (or both) is a design desition only you can make. Many different strategies can work and have different tradeoffs. Only you can tell what's right for your game.

Regarding threads: you don't need threads at all to do something like this. A single thread can work just fine. Threads may make sense or they may not. Depends heavily on the problem you are trying to solve and how parallel that problem is and how much synchronization overhead you get (not to mention all the other problems threading brings). Just be really sure you actually need threads and are prepared (and experienced enough) to deal with the complexity they bring, before you go that route.

[Ricky]

Hello, i have a few questions.

I have created a TCP server with socket selector and it supports multiple clients.
The game would be multiplayer only, 10 clients max.

-The question is should i make that the server runs the simulation and checks collision and then it
    sends positions/moving direction to clients, and the clients sends moving directions and when they preform some action like shoot jump?

-One more thing, what part should be in another thread on server and on a client?
    I tought about creating one thread for sending and one for receiving, both for server and client.

-PS. is there any difference between sending packets and char array?
    Currently i am sending a char[] and it works ok, but i thing packets would be a lot simpler.

On a side note TCP should not be used for multiplayer games due to all the overhead it introduces for reliability(read SLOOOOW). UDP is probably what you want.

[Jesper Juhl]

Depends on the game (a lot).
For some types of games TCP will be fine and the guarantees it gives you simplify things a lot.
For some games UDP is needed and the complexity you have to deal with (no guaranteed delivery mainly) is worth it.
But it depends on what you are doing.for example: for a networked chess game TCP is probably fine. For a real-time first-person-shooter it is probably not.

Just don't forget the complexity cost you have to pay when using UDP. It may be needed but it is not insignificant. TCP simplifies a lot of things, so if it is "good enough" it's a valid option.

[zsbzsb]

On a side note TCP should not be used for multiplayer games due to all the overhead it introduces for reliability(read SLOOOOW). UDP is probably what you want.

Tell that to Blizzard, who uses TCP for probably one of the largest MMOGs ever (World of Warcraft which is a real-time game). For what its worth, use TCP for any networking. It is highly unlikely that you will even see a difference if you implemented your own protocol in UDP. By the time you finally get your own reliable protocol implemented in UDP you are going to end up with much of the same overhead (if not more) than what TCP already provides.

[Jesper Juhl]

And if you do need UDP and reliable transport, then rather than building your own solution I'd recommend looking into ENet first.

[Ricky]

Err, http://gafferongames.com/2015/09/12/is-it-just-me-or-is-networking-really-hard/

Didn't know that about Blizzard though. I snooped around and found that someone had actually commented about this on one of Glenn's earlier posts dealing with TCP vs UDP.

TERA uses only TCP for network communications, which you can verify using WireShark — it’s not against the Terms of Service. Full disclosure: I helped publish TERA but didn’t code the game itself.

And incidentally, as the Guild Wars programmer who wrote the client->server communication protocol, the server->server communication protocol, and the low-level network libraries (among other things), I want to caution folks about making assumptions about why we chose to use TCP for Guild Wars (or why Blizzard chose TCP for WoW). We didn’t pick TCP for Guild Wars because it was unequivocally the best choice; it was a trade-off.

It probably warrants a blog article, but the reason Guild Wars uses TCP is that I felt the labor required to write a reliable transport layer on top of UDP would take too long: we’d run out of money fooling around writing transport code instead of writing a game.

So I chose to write Guild Wars on top of TCP, and if it didn’t work out I could rewrite the client transport layer to use UDP. Fortunately TCP worked well enough for client->server code.

But there is a big downside to TCP that I should mention beyond what Glenn talked about: you lose control of when connections terminate. So if a router fails-over in your datacenter, or if one of your bandwidth providers fails, you’ll likely drop all your TCP connections traveling over that route. With UDP it’s possible to just ignore the loss of connectivity, wait for routes to re-converge through a different router or bandwidth provider, and keep going.

So in short, Glenn knows what he’s talking about!

But you two are probably right, for what this user needs TCP will probably save him a lot of headaches. It sucks when you just want to start working on the game but have to work on a ton of back bone stuff first.

[Godsend72]

Thank you all for the info.

For now I'll stick with TCP and one thread. It works fine, but i think i will rewrite the code to send packets.

For now the clients are handeling logic, i will try to test it other way around and see how will that go.