Annotation of 43BSDReno/share/doc/smm/13.kchanges/netns.t, revision 1.1

1.1     ! root        1: .\" Copyright (c) 1986 Regents of the University of California.
        !             2: .\" All rights reserved.  The Berkeley software License Agreement
        !             3: .\" specifies the terms and conditions for redistribution.
        !             4: .\"
        !             5: .\"    @(#)netns.t     1.3 (Berkeley) 4/11/86
        !             6: .\"
        !             7: .NH
        !             8: Xerox Network Systems Protocols
        !             9: .PP
        !            10: 4.3BSD now supports some of the Xerox NS protocols.
        !            11: The kernel will allow the user to send or receive IDP datagrams directly,
        !            12: or establish a Sequenced Packet connection.
        !            13: It will generate Error Protocol packets when necessary,
        !            14: and may close user connections if this is the appropriate action on
        !            15: receipt of such packets.
        !            16: It will respond to Echo Protocol requests.
        !            17: The Routing Information Protocol is executed by a user level process,
        !            18: and sufficient access has been left for other protocols to be implemented
        !            19: using IDP datagrams.
        !            20: It would be possible to set the additional fields required for the Packet
        !            21: Exchange format at user level, to provide a daemon to respond to 
        !            22: time-of-day requests, or conduct an expanding ring broadcast to
        !            23: discover clearinghouses.
        !            24: .PP
        !            25: Wherever possible, the algorithms and data structures parallel those
        !            26: used in Internet protocol support,
        !            27: so that little extra effort should be required to maintain the NS protocols.
        !            28: There has not yet been much effort at tuning.
        !            29: .NH 2
        !            30: Naming
        !            31: .PP
        !            32: A machine running 4.3 is allowed to have only one six-byte NS host address,
        !            33: but is permitted to be on several networks.
        !            34: As in the Internet case, an address of all zeros may be used to
        !            35: bind the host address for an offered service.
        !            36: Unlike the Internet case, an address of all zeros cannot be used
        !            37: to contact a service on the same machine.  (This should be changed.)
        !            38: .PP
        !            39: There is only one name space of port numbers, as opposed to the Internet
        !            40: case where each protocol has its own port space.
        !            41: .PP
        !            42: Several point-to-point connections can share the same network number.
        !            43: The destination of a point-to-point connection can have a different
        !            44: network number from the local end.
        !            45: .PP
        !            46: The files \fIns.h\fP, \fIns_pcb.h\fP, \fIns.c\fP,
        !            47: \fIns_pcb.c\fP and \fIns_proto.c\fP are direct
        !            48: translations of similarly named files in the netinet directory.
        !            49: \fINs_pcbnotify\fP differs a little from \fIin_pcbnotify\fP in that it takes
        !            50: an extra parameter which it will pass to the ``notification''
        !            51: routine argument indirectly, by stuffing it in each NS control block
        !            52: selected.
        !            53: .PP
        !            54: This header file \fIns_if.h\fP contains the declaration of the NS
        !            55: variety of the per-interface address information, like \fInetinet/in_var.h\fP.
        !            56: .NH 2
        !            57: Encapsulations
        !            58: .PP
        !            59: The stipulation that each host is allowed exactly one 6 byte address
        !            60: implies that each 10 Mb/s Ethernet interface other than the first
        !            61: will need to reprogram its physical address.
        !            62: All the 10 Mb/s Ethernet drivers supplied with 4.3BSD perform this.
        !            63: The 3 Mb/s Ethernet driver does not perform any address resolution,
        !            64: but uses the 6th byte of the NS host address as a PUP host number,
        !            65: making it largely incompatible with altos running XNS.
        !            66: In a system with both 3 Mb/s and 10 Mb/s Ethernets,
        !            67: one should configure the 3 Mb/s network first.
        !            68: .PP
        !            69: The file \fIns_ip.c\fP contains code
        !            70: providing a mechanism for sending XNS packets over any medium supporting
        !            71: IP datagrams.
        !            72: It builds objects that look like point-to-point interfaces
        !            73: from the point of view of NS, and a protocol from the point of view of IP.
        !            74: Each of these pseudo interface structures
        !            75: has extra IP data at the end (a route, source and destination),
        !            76: and fits exactly into an mbuf.
        !            77: If the \fIifnet\fP structure grows any larger,
        !            78: the extra data will have to be put in a separate mbuf,
        !            79: or the whole scheme will have to be reworked more rationally.
        !            80: .NH 2
        !            81: Datagrams
        !            82: .PP
        !            83: The files \fIns_input.c\fP and \fIns_output.c\fP contain the base level
        !            84: routines which interact with network interface drivers.
        !            85: There is a kernel variable \fIidp_cksum\fP, which can be used to defeat
        !            86: checksums for all packets.
        !            87: (There ought to be an option per socket to do this).
        !            88: The NS output routine manages a cached route in the protocol
        !            89: control block of each socket.
        !            90: If the destination has changed, the route has been marked down,
        !            91: or the route was freed because of a routing change, a new route
        !            92: is obtained.
        !            93: The route is not used if the NS_ROUTETOIF (aka SO_DONTROUTE or MSG_DONTROUTE)
        !            94: option is present.
        !            95: .PP
        !            96: The files \fIidp.h\fP, \fIidp_var.h\fP, and \fIidp_usrreq.c\fP are the analogues
        !            97: of \fIudp.h\fP, \fIudp_var.h\fP, and \fIudp_usrreq.c\fP.
        !            98: .NH 2
        !            99: Error and Echo protocols
        !           100: .PP
        !           101: Routines for processing incoming error protocol packets
        !           102: are in \fIns_error.c\fP.  They call \fIctlinput\fP routines for IDP and
        !           103: SPP to maintain structural similarity to the Internet implementation.
        !           104: The kernel will generate error messages indicating lack
        !           105: of a listener at a port, incorrectly received checksum,
        !           106: or that a packet was thrown away due to insufficient resources
        !           107: at the recipient (buffer full).
        !           108: The echo protocol is handled as a special case.
        !           109: If there is no listener at port number 2, then the routine
        !           110: that generates the ``no listener'' error message will inspect
        !           111: the packet to see if it was an echo request, and if so, will
        !           112: echo it.
        !           113: Thus, the user is free to construct his own echoing daemon
        !           114: if he so chooses.
        !           115: .NH 2
        !           116: Sequenced Packet Protocol
        !           117: .PP
        !           118: In general, this code employs the Internet TCP algorithms where possible.
        !           119: By default, a three-way handshake is used in establishing connections.
        !           120: There is a compile time option to employ the minimal two way
        !           121: handshake.
        !           122: Incoming connections may multiplexed by source machine and port, as in the
        !           123: Internet case.
        !           124: It will switch over ports when establishing connections if requested to do so.
        !           125: .PP
        !           126: The retransmission timing and strategies are much like those of TCP,
        !           127: though recent performance enhancements have not yet migrated here.
        !           128: There has not yet been much opportunity to tune this implementation.
        !           129: The code is intended to generate keep-alive packets,
        !           130: though there is some evidence this isn't working yet.
        !           131: The TCP source-quench strategy hasn't been added either.
        !           132: The default nominal packet size is 576 bytes, and the default
        !           133: amount of buffering is 2048.
        !           134: It is possible to raise both by setting appropriate socket options.

unix.superglobalmegacorp.com

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