Suppose I have a server and a client. When I send a message to the client, would I be sending a ServerMessage, or a ClientMessage? The other way to think about it - when I receive a message, it is a ClientMessage or a ServerMessage? Or is it ClientMessage in both cases?!

  • 6
    Maybe it's just a Message in all cases. Does it need to be different? – joshp Feb 10 at 22:29
  • Some places speak of servers sending down-stream messages to clients and clients sending up-stream messages to the server. However, Josph is right, both are messages. – Laiv Feb 11 at 6:51
  • 1
    Given there are only two parties in involved in the communication, and a single message can only go one way, distinguishing either the originator or the recipient seems redundant. Call it a message. – richzilla Feb 11 at 10:14

If possible, use a different naming scheme that allows for more meaningful and less ambiguous names. Then choose names so that they reflect what the message is (or what kind of data it contains), rather then who the sender/recipient is. You could then document the kinds of messages each party can send.

Depending on the domain, the names themselves, if chosen well, may be able to implicitly indicate the originator - e.g., the business logic may be such that a certain kind of message can only be sent by, say, the server.

If you need to disambiguate who the sender is in documentation, then you can use a clarifying phrase, e.g. "client-sent message", or "server-sent message". If you need to clarify at which end some processing happens, use "client-side" and "server-side".

Alternatively, assuming an active client and passive (reactive) server, you can use the request/response terminology. The client always sends requests, while the server always returns responses.

As for "client message" / "server message", while you could use that, as you yourself have noticed, different people could interpret that in different ways, and that could be a source of unnecessary confusion. You'd have to pick one of the two meanings, document your choice somewhere ("within this project, client message means [...], and server message means [...]"), and you'd have to make sure that these terms are used consistently throughout - but that may prove difficult, especially if new people join the project.


How about making the names more descriptive?



That way it's clear where it goes.


Ordinarily, though this does somewhat depend on the protocol, I would think a client (or whatever's originating the connection) would send a request, which the server would receive and then answer with a response. The contents of either would be a body, and (again, depending on the protocol) metadata could be sent in a header or footer.


It's pretty ambiguous. Ultimately, it's defined by your context:

  • Strict source-centric context: "Where did the message come from?" A server sends a ServerMessage, which is received by the client as a ServerMessage. The client sends a ClientMessage, which is received by the server as a ClientMessage.

  • Strict destination-centric context: "Where is this message going?". A server sends a ClientMessage, which is received by the client as a ClientMessage. The client sends a ServerMessage, which is received by the server as a ServerMessage.

  • Source/Destination-centric context: "Is this message from me?" A server sends a ClientMessage, which is received by the client as a ServerMessage. The client sends a ServerMessage, which is received by the server as a ClientMessage.

So it can be really ambiguous - somebody reading the code won't really know what context is being used. This is the reason why other authors are suggesting that the naming convention is changed (such as MessageToClient or MessageToServer).

My personal preference is to just call it a Message.


Name the messages sent from the server to the client "S2CMessages" and the messages sent in the other direction "C2SMessages". That way there is no confusion about which way the message flows.

  • 4
    You have swapped ambiguous names for cryptic ones. This is not an improvement. – David Arno Feb 11 at 8:10
  • @DavidArno What's cryptic about S2C and C2S? AFAICT they are pretty usual terms in game networking. – immibis Feb 11 at 21:14

Your Answer

