![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to netns.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 13.kchanges|
Return to netns.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 13.kchanges |
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.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.