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