How are client server applications implemented? (server side) (asking about concept)

Question

I am making a simple online tic tac toe game (multiplayer). where the client side is java (android) server side is python (linux on a shared hosting server)

My question is about the server side: I was first thinking of having one socket (because I am only allowed to use one port on the server), then it waits for 2 users to connect and pairs them together, start a new thread to deal with them, then waits for another 2 users and so on. But after reading here alot about multithreading I found out that the server can handle at most 20 threads. So I tried using processes instead of threads but I got the same result. Moreover, I found out that the socket can handle at most 50 connections.

Any Ideas? Thanks

Answer 1

To scale without bounds, if you control the client code (so you know people aren't cheating -- which at tic-tac-toe they'd be unlikely to:-), you could have the client open and offer a listening socket in order to connect -- when an odd client connects, just respond with a "please wait" message; when the even client connects to match it up, respond to both clients with the listening-socket info about each other, and get out of the way.

That won't work for clients who can't open, and listen on, a new socket (eg, ones sequestered behind some NAT arrangement). In such a situation, you could switch the clients (for their follow-on interactions with one another) to UDP to/from your server -- UDP, not being connection oriented, can serve arbitrarily high numbers of clients (client pairs, in your case!) on a single socket (but then you're responsible, cooperatively on the client and server sides!, for checking/acknowledging packets and ensuring their good ordering, which TCP, being connection-oriented, handles on your behalf:-).

I'm not sure where exactly all of your constraints come from in the first place, or what other constraints (such as clients being unable to open, communicate, and listen to, new sockets...) might apply.

But one way or another, once you fully understand and tell us about all the applicable constraints, some solution can always be found (perhaps with new-fangled conniptions such as pub-sub, eg https://cloud.google.com/pubsub/docs -- as fast as new constraints arise, or faster!, clever guys are always figuring out work-arounds...!-)