Referring to the Stack Overflow question Protocol Terminology: Message versus Packet, I would like to relate the following accepted opinion to the MQTT protocol.
These are definitely messages. A "packet" is a layer-3 (in ISO terminology) protocol unit, such as an IP packet; and a "datagram" is a layer-1 or layer-2 unit, such as the several Ethernet datagrams that might make up the fragments of an IP packet.
So a message might be split across several packets, particularly if you're using a streaming protocol such as TCP, and a packet might be split across several datagrams.
The MQTT protocol defines control packets.
The MQTT protocol works by exchanging a series of MQTT Control Packets in a defined way.
Referring to the accepted answer of the linked Stack Overflow question, is MQTT using the word packet incorrect? Or is there something else to consider which makes the use of the word packet correct?
Words have no intrinsic meaning; they mean what we agree they mean. As the answer mentions "ISO terminology" lets start with the definition for "Packet" given in the ISO "Information technology — Vocabulary" (ISO/IEC 2382:2015):
sequence of bits arranged in a specific format, containing control data and possibly user data, and that is transmitted and switched as a whole
Whether an MQTT Control packet meets this definition will depend upon how you interpret "transmitted and switched as a whole".
The definition differs somewhat elsewhere; even in other ISO standards. A quick search found ISO/IEC 14476-1:2002 which defines "Packet" more in line with the way the answer you refer to does:
Represents a unit of transport data, which is equivalent to a segment in TCP/IP and a transport protocol data unit (TPDU) in OSI model...
So I guess the definition depends upon the context. Having said that, I believe that its difficult to argue that the usage in the MQTT spec is incorrect "in ISO terminology". I say this because the MQTT spec is, in fact, an ISO standard (ISO/IEC 20922:2016) which includes the definition for "MQTT Control Packet":
A packet of information that is sent across the Network Connection. The MQTT specification defines fourteen different types of Control Packet, one of which (the PUBLISH packet) is used to convey Application Messages.
Related
In networking, and more specifically in serial point-to-point communication (e.g. HDLC or PPP), is there any accepted terminology for the process or the entity that converts a stream of bytes (e.g., from a serial RS-232 link) into frames (e.g. HDLC frames) for further processing by higher network layers?
I have come across different potential terms, e.g. "framer", "parser", "decoder", ... but these might actually have different established meanings and I am not sure whiche one is appropriate.
What you are asking about is actually the purpose of HDLC, which is more of a concept than a standard. Each vendor implements it own version of HDLC, and they are not compatible with each other. HDLC is designed to frame a stream of bits, and the encapsulation parts of other Data-Link Layer protocols are modeled after HDLC.
The IEEE LAN protocols use a MAC (Media Access Control) sublayer to perform framing.
PPP uses what is called an encapsulation component to perform framing.
Both the IEEE LAN protocols and PPP modeled their respective framing components after HDLC, which itself is a framing component.
Recently I dug a bit deeper into the matter of network protocols and the OSI model, when noticed, that incoming TCP datagrams (correct me if this is the wrong term) are splitted into several parts, when they exceed a certain size - in this case it's propably my router's MTU. I captured those datagrams using SharpPcap in order to extract some information i am looking for, if you are wondering where I got this information from.
Anyway I was wondering if the reassembly of fragmented packets shouldn't be task of the IP layer, since it definitely provides information to accomplish this (id, fragmentation flags, fragment offset). Furthermore I read, that the TCP layer is to be interpreted as a stream-based protocol. But this actually implies, that it's up to the TCP layer to care about filling the application's buffer the right way, so that the initial piece of information is reconstructed and may be flushed "up" all further layers.
Before I made this observation I actually thought, that the TCP layer should care about reassembling those datagrams, but none of the mentioned layers does...
This leads to the following question(s):
Why are the TCP datagrams I receive not reassembled and what layer SHOULD actually take care about this?
The ip layer handles fragmentation and reassembly, http://en.wikipedia.org/wiki/IP_fragmentation.
When you use a tool like SharpPcap that uses winpcap/airpcap/libpcap, you are receiving the raw datagrams from the device you are capturing on. For many adapters this is an ethernet datagram that then contains an ip frame etc.
This is in contrast to data received after processing by the networking stack, where the reassembly is performed.
So, its expected that you won't get reassembled datagrams from SharpPcap (or many other capture libraries) because the data is being captured at the adapter level, not inside of our as an output of the networking stack that is performing reassembly.
You can perform the reassembly after capture either yourself or using a library that provides this functionality. You could also add such a component to Packet.Net (the packet processing library that SharpPcap is using) to provide this reassembly.
I have been studying a book on Computer Networking (this is not a homework question)
One of the questions compares ACK and NAK based data transfer protocols, with the emphasis being that for a NAK based protocol, packet loss can for packet x can be detected by the received when the (x + 1)th packet is received.
However, my issue is that what happens if the NAK sent by the receiver is lost before it gets to the sender? The sender will not be aware of errors and will not retransmit. Furthermore, what if the packet is the last one in the sequence? (there is no subsequent packet to test with)
I do not see how a NAK-only protocol can be reliable (delivers each packet in the correct order)
I suspect that the theoretical context described in the book assumes an infinite stream of packets and ignores conditions like the channel becoming completely disabled. In practice, there are other constructs defined as part of the ACK/NAK protocol or left up to higher or lower layer layer protocols to deal with. For instance, a physical layer would provide indications like "the channel is broken", and perhaps a protocol above sends/receives "end-of-stream" packets, with a timer detect the case where the NAK for the last packet is lost. These are just hypothetical examples, but are the types of things real-life protocols do.
I do not see how a NAK-only protocol can be reliable (delivers each
packet in the correct order)
I'm sure the book is implying there is some sort of mechanism for identifying packets in order. Otherwise, there would be no way for the receiver to indicate which packet it is NAK'ing, i.e., most protocols use a sequence number in each packet/ack/nak.
A NAK-only protocol can achieve reliability by having the receiver start a timer when sending a NAK and retransmit the NAK when the timer times out before the missing packet was retransmitted.
How does wireshark interpret physical packets?
As far as I know, all packets look to be the same, so how does it decode them to pass to next higher protocol?
When it's used to capture live traffic it knows the type of the interface and therefore the L2 encapsulation of packets, and when it reads a pcap file, the file has a field in the header indicating network type.
There are probably a number of different mechanisms. You can download the dissectors and study the source to find out the various methods.
I wrote a dissector for a network sniffer and ported it to Ethereal and then Wireshark (or maybe someone else ported it; I don't remember). But the basic logic is that the dissector gets added to the list of possible dissectors. Wireshark calls a dissector and it decodes the packet if it can. If not, it calls the next one in the chain.
In the code I wrote, I simply analyzed the packet (UDP in my situation) to determine if it fit the profile of the desired packet using checksums and known data in the packet. If it decided it was the packet I was interested in I just extracted the various pieces of interesting data from the packet. The function tvb_get_ptr returns a pointer to the start of the data.
In practice, what is the most appropriate term for the communications transmitted over a network in higher level protocols (those above TCP/IP, for example)? Specifically, I am referring to small, binary units of data.
I have seen both "message" and "packet" referred to in various client/server libraries, but I was interested in the community's consensus.
These are definitely messages. A "packet" is a layer-3 (in ISO terminology) protocol unit, such as an IP packet; and a "datagram" is a layer-1 or layer-2 unit, such as the several Ethernet datagrams that might make up the fragments of an IP packet.
So a message might be split across several packets, particularly if you're using a streaming protocol such as TCP, and a packet might be split across several datagrams.
Just my take. It probably depends on what level you are working at. When I think of the entire transmission (all headers, data, etc) I would call that a Message. A packet, especially in TCP/IP, is just a part of a message. Multiple packets are pushed across the network comprising an entire message.
I think packet refers to the chunks of data transferred on a lower layer like Ethernet and message is used for higher level information exchange.
imo they basically mean the same...
edit:
There's also another terminology called frame, which is defined in RFC 1122 as "the unit of transmission in a link layer protocol, and consists of a link-layer header followed by a packet." [wikipedia]
msgs is packet in Network Layer
it is segement in TCP protocol(Transmission Layer)
it is msgs in HTTP or FTP(Application Layer)