EMZETT.Message
In short: A general notification that a system sends to inform about its state or an event — not necessarily an error.
In more detail: In a networking context, for example status or control information such as ICMP type messages. The difference from an error message: a message can also communicate a normal, successful state (e.g. a confirmation), not just a problem.
In Depth
“Message” is the umbrella term for any kind of status information that a system sends proactively or as a reply — from a simple ping echo through a DHCP acknowledgement to a SYN-ACK reply during connection setup. The distinction matters: an error message is always a message, but not every message is an error — many protocols use the same message mechanism both for “everything’s fine” and for “here’s a problem” cases, distinguished only by a type or status code in the message’s header.
Overview of message types
In practice, network messages can be roughly divided into three categories:
- Confirmation messages — signal the successful completion of an operation, e.g. an ACK in the TCP handshake or a DHCP ACK message after a successful address assignment.
- Status messages — inform about the current state without anything having “happened”, e.g. an SNMP trap reporting a device’s current utilisation.
- Error messages — signal a problem, usually with a specific ICMP type or error code (see Error message).
Example: ICMP message header (simplified)
Type: 0 -> Echo Reply (confirmation, not an error)
Type: 3 -> Destination Unreachable (error)
Type: 11 -> Time Exceeded (error)
Here the same message frame (type + code + payload) carries completely different meanings depending on the type field — only the type code decides whether an application has to treat the message as a normal status or as an error. This reuse of a common format for many kinds of message is a widespread design pattern in network protocols: instead of defining a separate message format for every state, related messages share a common header and differ only in the type field.
Synchronously vs. asynchronously delivered messages
Some messages are direct replies to a specific request (e.g. a DNS answer to a query) — here the recipient knows exactly what the message refers to. Other messages are sent unsolicited (e.g. an SNMP trap on a threshold event) — the recipient has to assign the message to a context on its own, usually via a device or session ID in the payload.
See also: Error message, Header, ICMP types