Back to Basics: Data packets
Putting data in packages is basic to virtually all our networking concepts.
One of the things we take for granted every time we look at something on the Internet or an industrial control system is that our networks can send and receive data from any number of sources at the same time and it all seems to work. It wasn’t always like that, and we have the technology of data packets to thank for it.
In the early days of digital computing, devices communicated with each other using point-to-point serial communication. Basically the data flowed from device A to device B like water flowing through a pipe when both ends open the appropriate valves. It was crude, but it worked within its limitations. Early on that was tolerable because there were so few computers that had to communicate.
By the early 1960s, computers were becoming more numerous and the kind of data that was being communicated more critical. Paul Baran, who was working for the Rand Corporation, concluded that if data could be broken into chunks rather than a continuous flow, it could support a more robust system that could tie together far more devices via a common network. It might even be capable of withstanding a nuclear attack, which given that Cold War era, was a valid concern. Baran was a visionary and imagined systems like the Internet long before most people did.
What is a packet?
To return to the water flowing analogy, instead of sending water down a pipe, if you put it in a bottle, you can send it anywhere. Others compare data packets to letters, where a message is put in an envelope and carried by the post office.
A packet is a framework of a specific size and structure. It has a header and trailer at the beginning and end that identify who sent it, where it’s going, etc. In the middle there is a space for the message itself, or payload. For a given type of network, the payload has a length limitation so a longer message may have to be broken into multiple packets. If the message is short, the other parts of the packet don’t get any smaller. Various networking protocols do the details differently, but the basic concepts are largely the same. Applications on the sending and receiving ends put the data in packets for transmission and unpack it when it arrives.
Networking protocols are rated on their efficiency, or the amount of message payload compared to the overall packet size. If too much of the packet size is taken up with the header, trailer, and other overhead, that protocol is considered inefficient. Part of the argument against using Ethernet for field instrumentation is the idea that it has too much overhead for the small amount of data these devices generate.
One of the benefits of breaking larger data into smaller units is that it is possible to verify the accuracy of a message using an error checking protocol such as a cyclic redundancy check (CRC). In basic terms, all the information in the message in a given packet has a numerical value attached to it. The protocol adds up all those values and divides the sum by another number. The remainder from the calculation is assigned to that message. The receiver does the same calculation and verifies that it got the same remainder value. If it didn’t, it knows that some of the data in the message contained in that packet must have been corrupted and it flags that packet.
Ethernet communication depends on packets, or as they are more typically called, frames. Many variations have been created, but there are typically seven parts to a complete frame:
- Preamble (used for bit synchronization)
- SFD (start of frame delimiter)
- Destination MAC address
- Source MAC address
- Length or specific type
- Message or data payload, and
- FCS (frame check sequence).
The size of each of these elements is fixed, except for the payload. This can vary as needed for the information being sent, but there is a maximum of about 1.5 kB. This article, set in plain text, would likely require three packets to transmit.
As technologies go, it’s difficult to think of one that has been used and adapted in so many ways, and one that we depend on in so many applications.
Peter Welander is a content manager for Control Engineering. Reach him at pwelander(at)cfemedia.com.
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.