Decomposition of a UDP Packet

The above is an example of an UDP Header. UDP is an unreliable protocol where no attempt is made to keep track of packets as to being in a sequence, order, or verify that they were received. Checks are made to see if the packet appears to be the same packet transmitted by evaluation of a checksum and comparison to the packets checksum. These packets are dropped if the destination calculations of the checksum differs from the packets claimed checksum.

Description of fields listed in above UDP header starting from left to right, top to bottom.
• Source Port [SP] (16 bits): When a connection is attempted, or being conducted, this specifies what port the local machine is waiting to listen for responses from the destination machine.
• Destination Port [DP] (16 bits): When a user desires to connect up to a service on a remote machine, the Application Layer program specifies what port initial connections should use. When not as part of an initial connection, this specifies what port number is going to be used for the remote machine as a packet is being sent out to its destination.
• Length [Len] (16 bits): This allows for the receiving station to know how many of the incoming bits are supposed to be part of a valid packet. The length is a calculation of how many bytes are part of the UDP packet including bytes in the header. Since UDP always has 4 fields in the header and each has 16 bits, and the data/payload of variable length, we know the length will be 8 + (number of bytes in the payload.)
• UDP Checksum [UDPCS] (16 bits):This is a checksum that covers the header and data portion of a UDP packet to allow the receiving host to verify the integrity of an incoming UDP packet. The UDP packet is loaded with a predefined number in the checksum field, and then when the checksum is computed, then the checksum is written over the previous value. When the packet arrives at the destination, the destination machine's OS looks to the 4 header field (bytes made from bits 16 through 31) and pulls them out of the packet, then re-calculates the checksum on the packet without anything in the checksum field. Then the OS compares the checksum calculated with thte one that was transmitted in the packet. If the checksum is the same, the data is fine, and it is allowed to pass on through, but if there is a difference, the UDP packet, and data are dropped, and no attempt is made by the receiving machine to get a new copy, and the sending machine will not try to send that same packet. The packet is lost forever. UDP is not reliable! For a reliable Transport Layer TCP/IP suite protocol see the TCP packet.
• Data (Variable bits): As you might expect, this is the payload, or data portion of an UDP packet. The payload may be any number of protocols (often application layer.) Some of the most commonly used UDP protocols include NFS, DNS, as well as mutliple audio and video streaming protocols. If an error occurs in a UDP packet and an error is desired to be fixed, it is left to the application layer to find the error and request its application layer "hunk" or "chunk" of data.

This ends the brief preview of an UDP packet.

Comments and/or suggestions for this?: Email me at: dugan@passwall.com

Attempts have been made to make the tables appear as they should for LYNX users by forcing a common field width for fields being used by padding them with other printable characters. This is meant to allow for LYNX users to see the tables much like the Netscape and other web browser worlds might show them. However, from personal experience, some versions of LYNX still manage to munge the tables, making them use up several pages. It seems to be a problem with how earlier versions of LYNX dealt with tables, but the problem has not been entirely isolated.

Some have asked why this collection of on-line documents is so lacking of graphic content. To them I answer: faster downloads. Many of these pages are smaller than some pictures on many commercial web sites. You do not come here to look at my pictures. You come here to read content. Also, LYNX users benefit from this, and by using ALL text, people with ADA issues are able to use speech recognition software on the text to hear the words.

Copyright (C) 1999, 2000, 2001, 2002 by Michael Egan: All rights reserved.

A Special License: No part of this document may be used for profit without the consent of the author Michael Egan in writing. Content may be duplicated for retransmission for non-profit purposes as long as the copyright and license remain included in their entirety. The content is provided "as-is" and I take no responsibility on the content's truthfulness or consistency. Errors may exist in these documents, but acting upon these errors is left up to the reader to verify by a third party that will take responsibility for fact verification. When notified of errors or inconsistencies, attempts will be made to rectify the errors.

In plan English this is meant to do many things: This copyright is meant to exist so that others may not profit from this work as published in paper form, or by duplicating the content to place advertisements over it and generate income. It is also meant to exist to prevent people from publishing this work as their own and receiving profit from this process on research they did not perform. It is not meant to stop a professor from running off copies to use in their classes for their students. It is also not meant to stop the student from printing up copies for their own education. How depressing it would be to find your work published in book form without your permission, or compensation. Another reason for this Copyright is to limit the effect of the mistakes I have made within this document before I was able to complete it. It would be even sadder to notice my mistakes in print and criticized before I could resolve them. Eventually, after I finish this work, I may retain copyright, but eliminate the license.