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)
Related
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.
My firewall textbook says: "UDP breaks a message into numbered segments so that it can be transmitted."
My understanding was UDP had no sequence or other numbering scheme? That data was broken into packets and sent out with no ordered reconstruction on the other end, at least on this level. Am I missing something?
The book is just wrong here. The relevant section says:
User Datagram Protocol (UDP)—This protocol is similar to TCP in that it handles the addressing of a message. UDP breaks a message into numbered segments so that it can be transmitted. It then reassembles the message when it reaches the destination computer.
UDP does not include any mechanism to segment or reassemble messages; each message is sent as a single UDP datagram. If you look at the UDP "packet" (technically datagram) structure on page 108, there's no segment number or anything like that.
Mind you, segmentation can happen at other layers, either above or below UDP:
IP packets can be fragmented if they're too big for a network link's MTU (maximum transfer unit). This can happen to IP packets that contain UDP, TCP, or whatever. This is actually relevant for firewalls because creative fragmentation can sometimes be used to bypass packet filtering rules.
Some protocols that run on top of UDP also use something like numbered segments. For example, TFTP (trivial file transfer protocol) breaks files into "blocks", and transmits a block number in the header for each block. (And the receiver responds acknowledging the block number it's received -- it's like a drastically simplified version of TCP.) But this is part of the TFTP protocol, not part of UDP.
QUIC is another example of a protocol that runs over UDP and supports segmentation (and multiple connections, and...), and each packet contains a packet number. But again it's part of the QUIC protocol, not UDP.
we know that transport layer protocols like tcp control the flow and take care of the reliability by slide window and acknowledges ...etc. the data link layer with LLC sub layer has the same functionality for reliable connections also. the first question : is this means that both layers do the same functions twice? or when we use tcp in transport layer there is no need for LLC reliability functions ?how is it working ?
the second question: since IP layer is unreliable when it sends and receives packets, is this means that routers witch are layer 3 devices with no tcp protocol above it depends on LLC sub layer to takes care about the reliability "I mean between two routers" ?
I dont think you need other reliability, in words of disruption, both IP and Physical protocls (such as Ethernet) have CRC and Checksum in order to prevent disruption, but in terms of packet loss, TCP is what's called a stream protocol - it transfers you a stream of bytes, Sequence / Acknowledgment number server that purpose and help you keep track of bytes sent/read by client, if some weird "jump" in those numbers would be made, an ACK message wont be sent by receiving side, and protocol's sender would re-send lost packets hence I don't think that you need some reliability in terms of packet loss as TCP covers that for all downwards layers.... not sure I fully understood your question though, thats when we use TCP
about using pure IP and physical layer protocols, I honestly have no idea how to prevent packet-loss yet disruption is prevented by as mentioned earlier - checksums
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.
when connecting two network interface adapters directly (using just an ethernet cable, with no networking equipment whatsoever in between), is it correct to assume that all UDP packets sent from one NIC will be received by the other in the same ordering? (I know packet loss will still be a problem, but for this particular question I would like to focus on ordering).
Thanks!
You can't assume anything with UDP: delivery, non-duplication, sequence, ... The only exception is that if you do receive a datagram it is intact.
Theoretically no as UDP implementation in OSI level is at layer 4 i.e. transport layer and the underlying layer of UDP might decide to sequence the packets different way. Remember, the network layer (layer 3) is responsible for fragmentation and reassembly of data.
However, practically, depending on the implementation, it is quite safe to assume that the sequence will remain the same.