So I have TCP connection for stuff like leveing, player info, etc..And I have UDP datagram for stuff like player position, rotation, etc..Should I create new thread for both TCP and UDP on both client and server side?That won't be resource heavy on client side but on server side with up to 15 players that will be 30 new threads. I don't know if that amount if threads are not much or is there a better way of solving this issue.
\$\begingroup\$
\$\endgroup\$
4
-
\$\begingroup\$ What issue are you trying to solve? \$\endgroup\$– Vaillancourt ♦Commented Nov 15, 2019 at 22:19
-
\$\begingroup\$ @Vaillancourt I am thinking that openning that much threads is way too much.So I am asking if there is a better way? \$\endgroup\$– Vuk UskokovicCommented Nov 15, 2019 at 22:20
-
1\$\begingroup\$ @Ouew like keeping a list of connections and looping through them? Seems a lot simpler than keeping and managing a list of threads managing connections. \$\endgroup\$– JustWannaFlyCommented Nov 15, 2019 at 22:24
-
\$\begingroup\$ @JustWannaFly thats for TCP right.Thank you for that.But for UDP is one thread enough for receiving like 5 Packets/Sec per client? \$\endgroup\$– Vuk UskokovicCommented Nov 15, 2019 at 22:26
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
30 threads on the server is no big deal... much less on a dedicated server. My PC has, at the moment of writing, around 1750 open threads (in Windows, you can find this in the task manager).
Well, unless your hosting service limits that.
However, why do you need threads per client on the server?
In general you do not. A server thread for listening to UDP, and another for listening to TCP, would do. In fact, it is possible in a single thread (baring language and libraries).
Assuming you are using sockets, the messages from multiple clients get queued up. In addition, there is nothing preventing the server to send messages to different clients from the same thread.
Besides, you cannot open a port multiple times, and sharing a socket – if possible in whatever platform you are using – is a bad idea. Thus, we would be talking about assigning a different port to each client. Well, as I said above, the socket will queue messages from multiple clients, thus opening a port for each client is unnecessary.
If you really want to have multi-threading, remember that you can have a single thread listening and have it queue a task (on a thread pool, for example) to handle each message.
Also remember that the performance improvement you get is limited by the number of cores, and that you need to worry about threading issues. In particular, you want players to interact on the server, right? Thus, if every client is on a different thread you will need some kind of channels or shared memory at some point.
\$\begingroup\$
\$\endgroup\$
UDP, 15 players, 5 packets/sec = 75 packets/sec of UDP traffic. If the packets are maximally sized (65,507 data bytes), that is roughly 5MB/s. One thread should be plenty.
It may also be worth looking at this post: https://stackoverflow.com/questions/26578692/how-many-threads-is-good-for-a-datagram-receiver
Granted it's regarding Java, but datagrams are datagrams.
