Game server TCP networking sockets - fairness

Question

I'm writing a game server for a turn-based game. One criteria is that the game needs to be as fair for all players as possible.

So far it works like this:

• Each client has a TCP connection. (If relevant, the connection is opened via WebSockets)
• While running, continually check for incoming socket messages via epoll.
• Iterate through clients with sockets ready to read:
  • Read all messages from the client.
  • Update the internal game state for each message.
  • Queue outgoing messages to affected clients.
• At the end of each "window" (turn):
  • Iterate through clients and write all queued outgoing messages to their sockets

My concern for fairness raises the following questions:

Does it matter in which order I send messages to the clients?

• Calling write() on all the sockets takes only a fraction of a second for my program, but somewhere in the underlying OS or networking would it make a difference if I sorted the client list?
  • Perhaps I should be sending to the highest-latency clients first?

Does it matter how I write the outgoing messages to the sockets?

• Currently I'm writing them as one large chunk. The size can exceed a single packet.
  • Would it be faster for the client to begin its processing if I sent messages in smaller chunks than 1 packet?
  • Would it be better to write 1 packet worth to each client at a time, and iterate over the clients multiple times?

Are there any linux/networking configurations that would bear impact here?

Thanks in advance for your feedback and tips.

Answer 1

Does it matter in which order I send messages to the clients?

Yes, by fractions of milliseconds. If the network interface is available for sending the OS will immediately start sending. Why would it wait?

Perhaps I should be sending to the highest-latency clients first?

I think you should be sending in random order. Shuffle the list prior to sending. This makes it fair. I think your question is valid and this should be addressed.

Currently I'm writing them as one large chunk. [...]

First, realize that TCP is stream-based and that there are no packets/messages at the protocol level. On a physical level data is indeed packetized.

It is not necessary to manually split off packets because clients will read data as it arrives anyway. If a client issues a read, that read will complete immediately once the first packet has arrived. There is no artificial waiting in the OS.

Are there any linux/networking configurations that would bear impact here?

I don't know. Be sure to disable nagling.