Return to e.t CVS log

Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 15.net

Annotation of 43BSDReno/share/doc/smm/15.net/e.t, revision 1.1

1.1     ! root        1: .\" Copyright (c) 1983, 1986 The Regents of the University of California.
        !             2: .\" All rights reserved.
        !             3: .\"
        !             4: .\" Redistribution and use in source and binary forms are permitted
        !             5: .\" provided that the above copyright notice and this paragraph are
        !             6: .\" duplicated in all such forms and that any documentation,
        !             7: .\" advertising materials, and other materials related to such
        !             8: .\" distribution and use acknowledge that the software was developed
        !             9: .\" by the University of California, Berkeley.  The name of the
        !            10: .\" University may not be used to endorse or promote products derived
        !            11: .\" from this software without specific prior written permission.
        !            12: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
        !            13: .\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
        !            14: .\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
        !            15: .\"
        !            16: .\"    @(#)e.t 6.4 (Berkeley) 3/7/89
        !            17: .\"
        !            18: .nr H2 1
        !            19: .\".ds RH "Trailer protocols
        !            20: .br
        !            21: .ne 2i
        !            22: .NH
        !            23: \s+2Trailer protocols\s0
        !            24: .PP
        !            25: Core to core copies can be expensive.
        !            26: Consequently, a great deal of effort was spent
        !            27: in minimizing such operations.  The VAX architecture
        !            28: provides virtual memory hardware organized in
        !            29: page units.  To cut down on copy operations, data
        !            30: is kept in page-sized units on page-aligned
        !            31: boundaries whenever possible.  This allows data
        !            32: to be moved in memory simply by remapping the page
        !            33: instead of copying.  The mbuf and network
        !            34: interface routines perform page table manipulations
        !            35: where needed, hiding the complexities of the VAX
        !            36: virtual memory hardware from higher level code. 
        !            37: .PP
        !            38: Data enters the system in two ways: from the user,
        !            39: or from the network (hardware interface).  When data
        !            40: is copied from the user's address space
        !            41: into the system it is deposited in pages (if sufficient
        !            42: data is present).
        !            43: This encourages the user to transmit information in
        !            44: messages which are a multiple of the system page size.
        !            45: .PP
        !            46: Unfortunately, performing a similar operation when taking
        !            47: data from the network is very difficult.
        !            48: Consider the format of an incoming packet.  A packet
        !            49: usually contains a local network header followed by
        !            50: one or more headers used by the high level protocols. 
        !            51: Finally, the data, if any, follows these headers.  Since
        !            52: the header information may be variable length, DMA'ing the eventual
        !            53: data for the user into a page aligned area of
        !            54: memory is impossible without
        !            55: \fIa priori\fP knowledge of the format (e.g., by supporting
        !            56: only a single protocol header format).
        !            57: .PP
        !            58: To allow variable length header information to
        !            59: be present and still ensure page alignment of data,
        !            60: a special local network encapsulation may be used.
        !            61: This encapsulation, termed a \fItrailer protocol\fP [Leffler84],
        !            62: places the variable length header information after
        !            63: the data.  A fixed size local network
        !            64: header is then prepended to the resultant packet. 
        !            65: The local network header contains the size of the
        !            66: data portion (in units of 512 bytes), and a new \fItrailer protocol
        !            67: header\fP, inserted before the variable length
        !            68: information, contains the size of the variable length
        !            69: header information.  The following trailer
        !            70: protocol header is used to store information
        !            71: regarding the variable length protocol header:
        !            72: .DS
        !            73: ._f
        !            74: struct {
        !            75:        short   protocol;       /* original protocol no. */
        !            76:        short   length; /* length of trailer */
        !            77: };
        !            78: .DE
        !            79: .PP
        !            80: The processing of the trailer protocol is very
        !            81: simple.  On output, the local network header indicates that
        !            82: a trailer encapsulation is being used.
        !            83: The header also includes an indication
        !            84: of the number of data pages present before the trailer
        !            85: protocol header.  The trailer protocol header is
        !            86: initialized to contain the actual protocol identifier and the
        !            87: variable length header size, and is appended to the data
        !            88: along with the variable length header information.
        !            89: .PP
        !            90: On input, the interface routines identify the
        !            91: trailer encapsulation
        !            92: by the protocol type stored in the local network header,
        !            93: then calculate the number of
        !            94: pages of data to find the beginning of the trailer. 
        !            95: The trailing information is copied into a separate
        !            96: mbuf and linked to the front of the resultant packet.
        !            97: .PP
        !            98: Clearly, trailer protocols require cooperation between
        !            99: source and destination.  In addition, they are normally
        !           100: cost effective only when sizable packets are used.  The
        !           101: current scheme works because the local network encapsulation
        !           102: header is a fixed size, allowing DMA operations
        !           103: to be performed at a known offset from the first data page
        !           104: being received.  Should the local network header be
        !           105: variable length this scheme fails. 
        !           106: .PP
        !           107: Statistics collected indicate that as much as 200Kb/s
        !           108: can be gained by using a trailer protocol with
        !           109: 1Kbyte packets.  The average size of the variable
        !           110: length header was 40 bytes (the size of a
        !           111: minimal TCP/IP packet header).  If hardware
        !           112: supports larger sized packets, even greater gains
        !           113: may be realized.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.