At 05:06 PM 9/23/2002 -0700, Dave Crocker wrote:
There is no strict, formal, official distinction between packet or
datagram. The tendency is to use packet for referring to the
lower-levels, and datagram at the higher. But how high or how low?
I'll disagree with that. A packet is a unit of data carried in a packet
network, regardless of the layer. For some reason, we generally refer to
layer two packets as 'frames' (such as Ethernet, Frame relay, or LAPB
'frames'), X.25 packets as 'packets', and TCP packets as 'segments'. I can
point out literature that refers to each of those as 'packets'. I tend to
view that as the idiom of the writer of the specification, as there is
nothing uniform about it.
But a datagram is quite clearly defined. RFC 753 is the first RFC to use
the term: it defines
internet datagram
The unit of data exchanged between a pair of internet modules
(includes the internet header).
More generally, RFC 1594 defines it in these terms:
Datagram
A self-contained, independent entity of data carrying
sufficient information to be routed from the source
to the destination computer without reliance on earlier
exchanges between this source and destination computer and
the transporting network.
Now, the User Datagram Protocol accomplishes something that the BBN
Transport (the precursor to ISO's TP 4) did: it enables a user application
to specify a packet of arbitrary size and a destination, and send the data
to the destination. TP 4 did it using a reliable protocol; UDP does it by
fragmenting the single 'packet' as necessary and blasting the lot at the
destination. The two have about the same API, though; from the
application's perspective, a wad of data is directed to a specified
destination, and the application can essentially fire and forget. (I won't
discuss probability of successful delivery :^)
I could imagine the APEX folks using the term "datagram" in that latter sense.