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?!

Maybe it's just a Message in all cases. Does it need to be different?
– joshpFeb 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.
– LaivFeb 11 at 6:51

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.
– richzillaFeb 11 at 10:14

4 Answers
4

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.

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).