![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to netinet.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 netinet.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: .\" @(#)netinet.t 1.8 (Berkeley) 4/11/86 ! 6: .\" ! 7: .hw SUBNETSARELOCAL ! 8: .NH ! 9: Internet network protocols ! 10: .PP ! 11: There are numerous bug fixes and extensions in the Internet ! 12: protocol support (\fB/sys/netinet\fP). ! 13: This section describes some of the more important changes ! 14: with very little detail. ! 15: As many of the changes span several source files, ! 16: and as it is very difficult to merge this code with earlier versions ! 17: of these protocols, ! 18: it is strongly recommended that the 4.3BSD network be adopted ! 19: intact, with local hacks merged into it only if necessary. ! 20: .NH 2 ! 21: Internet common code ! 22: .PP ! 23: By far, the most important change in IP and the shared Internet support ! 24: layer is the addition of subnetwork addressing. ! 25: This facility is used (and required) by a number of large university ! 26: and other networks that include multiple physical networks ! 27: as well as connections with the DARPA Internet. ! 28: Subnet support allows a collection of interconnected local networks ! 29: to share a single network number, ! 30: hiding the complexity of the local environment and routing ! 31: from external hosts and gateways. ! 32: The subnet support in 4.3BSD conforms with the Internet standard ! 33: for subnet addressing, RFC-950. ! 34: For each network interface, a network mask is set along with the address. ! 35: This mask determines which portion of the address is the network number, ! 36: including the subnet, and by default is set according to the network ! 37: class (A, B, or C, with 8, 16, or 24 bits of network part, respectively). ! 38: Within a subnetted network each subnet appears as a distinct network; ! 39: externally, the entire network appears to be a single entity. ! 40: .PP ! 41: Another important change in IP addressing ! 42: is a change to the default IP broadcast address. ! 43: The default broadcast address is the address with a host part of all ones ! 44: (using the definition INADDR_BROADCAST), ! 45: in conformance with RFC-919. ! 46: In 4.2BSD, the broadcast address was the address with a host part ! 47: of all zeros (INADDR_ANY). ! 48: To facilitate the conversion process, ! 49: and to help avoid breaking networks with forwarded broadcasts, ! 50: 4.3BSD allows the broadcast address to be set for each interface. ! 51: IP recognizes and accepts network broadcasts ! 52: as well as subnet broadcasts when subnets are enabled. ! 53: Such broadcasts normally originate from hosts that do not know about subnets. ! 54: IP also accepts old-style (4.2) broadcasts using a host part of all ! 55: zeros, either as a network or subnet broadcast. ! 56: An address of all ones ! 57: is recognized as ``broadcast on this network,'' and an address of all ! 58: zeros is accepted as well. ! 59: The latter two are sometimes used in ! 60: broadcast information requests or network mask requests in the course ! 61: of starting a diskless workstation. ! 62: ICMP includes support for the Network Mask Request and Response. ! 63: A new routine, \fIin_broadcast\fP, ! 64: was added for the use of link layer output routines ! 65: to determine whether an IP packet should be broadcast. ! 66: .PP ! 67: Network numbers are now stored and used unshifted to ! 68: minimize conversions and reduce the overhead associated with comparisons. ! 69: 4.2BSD shifted network numbers to the low-order part of the word. ! 70: The structure defining Internet addresses no longer includes ! 71: the old IMP-host fields, but only a featureless 32-bit address. ! 72: .XP in.h ! 73: The definitions of Internet port numbers in this file ! 74: were deleted, as they have been superceded by the \fIgetservicebyname\fP ! 75: interface. ! 76: A definition was added for the single ! 77: option at the IP level accessible through \fIsetsockopt\fP, ! 78: IP_OPTIONS. ! 79: .XP in_pcb.h ! 80: The Internet protocol control block includes a pointer to an optional ! 81: mbuf containing IP options. ! 82: .XP in_var.h ! 83: This new header file contains the declaration of the Internet ! 84: variety of the per-interface address information. ! 85: The \fIin_ifaddr\fP structure includes the network, subnet, network mask ! 86: and broadcast information. ! 87: .XP in.c ! 88: The \fIif_*\fP routines which manipulate Internet addresses ! 89: were renamed to \fIin_*\fP. ! 90: \fIin_netof\fP and \fIin_lnaof\fP check whether the address ! 91: is for a directly-connected network, and if so they use the local ! 92: network mask to return the subnet/net and host portions, respectively. ! 93: \fIin_localaddr\fP determines whether an address corresponds ! 94: to a directly-connected network. ! 95: By default, this includes any subnet of a local network; ! 96: a configuration option, SUBNETSARELOCAL=0, changes this to return ! 97: true only for a directly-connected subnet or non-subnetted network. ! 98: Interface \fIioctl\fPs that get or set addresses or related status information ! 99: are forwarded to \fIin_control\fP, which implements them. ! 100: \fIin_iaonnetof\fP replaces \fIif_ifonnetof\fP for Internet addresses only. ! 101: .XP in_pcb.c ! 102: The destination address of a \fIconnect\fP may be given as INADDR_ANY (0) ! 103: as a shorthand notation for ``this host.'' ! 104: This simplifies the process of connecting to local servers ! 105: such as the name-domain server that translates host names to addresses. ! 106: Also, the short-hand address INADDR_BROADCAST is converted to the broadcast ! 107: address for the primary local network; it fails if that network ! 108: is incapable of broadcast. ! 109: The source address for a connection or datagram ! 110: is selected according to the outgoing interface; ! 111: the initial route is allocated at this time and stored ! 112: in the protocol control block, so that it may be used again ! 113: when actually sending the packet(s). ! 114: The \fIin_pcbnotify\fP routine was generalized to apply any function ! 115: and/or report an error to all connections to a destination; ! 116: it is used to notify connections of routing changes and other ! 117: non-error situations as well as errors. ! 118: New entries have been added to this level to invalidate cached ! 119: routes when routing changes occur, ! 120: as well as to report possible routing failures detected by ! 121: higher levels. ! 122: .XP in_proto.c ! 123: The protocol switch table for Internet protocols includes entries ! 124: for the \fIctloutput\fP routines. ! 125: ICMP may be used with raw sockets. ! 126: A raw wildcard entry allows raw sockets to use any protocol ! 127: not already implemented in the kernel (e.g., EGP). ! 128: .NH 2 ! 129: IP ! 130: .PP ! 131: Support was added for IP source routing and other IP options ! 132: (partly derived from BBN's implementation). ! 133: On output, IP options such as strict or loose source route and record ! 134: may be set by a client process using TCP, UDP or raw IP sockets. ! 135: IP properly updates source-route and record-route options ! 136: when forwarding (and leaves them in the packet, unlike 4.2 which ! 137: stripped them out after updating). ! 138: IP input preserves any source-routing information in an incoming packet ! 139: and passes it up to the receiving protocol upon request, ! 140: reversing it and arranging it in the same way as user-supplied options. ! 141: Both TCP and ICMP retrieve incoming source routes for use in replies. ! 142: Most of the option-handling code has been converted to use ! 143: \fIbcopy\fP instead of structure assignments when copying addresses, ! 144: as the alignment in the incoming packet may not be correct for the host. ! 145: This is not required on the VAX, but is needed on most other machines ! 146: running 4.2BSD. ! 147: .XP ip.h ! 148: The IP time-to-live field is decremented by one when forwarding; ! 149: in 4.2BSD this value was five. ! 150: .XP ip_var.h ! 151: Data structures and definitions were added for storing ! 152: IP options. ! 153: New fields have been added to the structure containing IP statistics. ! 154: .XP ip_input.c ! 155: The changes to save and present incoming IP source-routing information ! 156: to higher level protocols are in this file. ! 157: The identity of the interface that received the packet is also ! 158: determined by \fIip_input\fP and passed to the next protocol ! 159: receiving the packet. ! 160: To avoid using uninitialized data structures, ! 161: IP must not begin receiving packets until at least one Internet address ! 162: has been set. ! 163: A bug in the reassembly of IP packets with options has been corrected. ! 164: Machines with only a single network interface (in addition to the loopback ! 165: interface) no longer attempt to forward received IP packets that are ! 166: not destined for them; ! 167: they also do not respond with ICMP errors unless configured with ! 168: the GATEWAY option. ! 169: This change prevents large increases in network activity which used to result ! 170: when an IP packet that was broadcast was not understood as a broadcast. ! 171: A one-element route cache was added to the IP forwarding routine. ! 172: When a packet is forwarded using the same interface on which it arrived, ! 173: if the source host is on the directly-attached network, ! 174: an ICMP redirect is sent to the source. ! 175: If the route used for forwarding was a route to a host ! 176: or a route to a subnet, ! 177: a host redirect is used, otherwise a network redirect is sent. ! 178: The generation of redirects may be disabled by a configuration option, ! 179: IPSENDREDIRECTS=0. ! 180: More statistics are collected, in particular on traffic and fragmentation. ! 181: The \fIip_ctlinput\fP routine was moved to each of the upper-level ! 182: protocols, as they each have somewhat different requirements. ! 183: .XP ip_output.c ! 184: The IP output routine manages a cached route in the protocol ! 185: control block for each TCP, UDP or raw IP socket. ! 186: If the destination has changed, the route has been marked down, ! 187: or the route was freed because of a routing change, a new route ! 188: is obtained. ! 189: The route is not used if the IP_ROUTETOIF (aka SO_DONTROUTE or MSG_DONTROUTE) ! 190: option is present. ! 191: Preformed IP options passed to \fIip_output\fP are inserted, ! 192: changing the destination address as required. ! 193: The \fIip_ctloutput\fP routine allows options to be set for an individual ! 194: socket, validating and internalizing them as appropriate. ! 195: .XP raw_ip.c ! 196: The type-of-service and offset fields in the IP header ! 197: are set to zero on output. ! 198: The SO_DONTROUTE flag is handled properly. ! 199: .NH 2 ! 200: ICMP ! 201: .PP ! 202: There have been numerous fixes and corrections to ICMP. ! 203: Length calculations have been corrected, allowing ! 204: most ICMP packet lengths to be received and allowing errors ! 205: to be sent about smaller input packets. ! 206: ICMP now uses information about the interface on which a message ! 207: was received to determine the ! 208: correct source address on returned error packets ! 209: and replies to information requests. ! 210: Support was added for the Network Mask Request. ! 211: Responses to source-routed requests use the reversed source route ! 212: for the return trip. ! 213: Timestamps are created with \fImicrotime\fP, allowing 1-millisecond ! 214: resolution. ! 215: The \fIicmp_error\fP routine is capable of sending ICMP redirects. ! 216: When processing network redirects, the returned source address is converted ! 217: to a network address before passing it to the routing redirect handler. ! 218: The translation of ICMP errors to Unix error returns was updated. ! 219: .NH 2 ! 220: TCP ! 221: .PP ! 222: In addition to bug fixes, several performance changes have been ! 223: made to TCP. ! 224: Several of these address overall network performance and congestion ! 225: avoidance, while others address performance of an individual connection. ! 226: The most important changes concern the TCP send policy. ! 227: First, the sender silly-window syndrome avoidance strategy was fixed. ! 228: In 4.2BSD, the amount that could be sent was compared to the offered window, ! 229: and thus small amounts could still be sent if the receiver offered ! 230: a silly window. ! 231: Once this was fixed, there were problems with peers that never offered ! 232: windows large enough for a maximum segment, or at least 512 bytes ! 233: (e.g., the peer is a TAC or an IBM PC). ! 234: Code was then added to maintain estimates of the peer's receive and send ! 235: buffer sizes. ! 236: The send policy will now send if the offered ! 237: window is at least one-half of the receiver's buffer, as well as when ! 238: the window is at least a full-sized segment. ! 239: (When the window is large enough for all data that is queued, ! 240: the data will also be sent.) ! 241: The send buffer size estimate is not yet used, but is desired for a new ! 242: delayed-acknowledgement scheme that has yet to be tested. ! 243: Another problem that was exposed when the silly-window avoidance was fixed ! 244: was that the persist code didn't expect to be used with a non-zero window. ! 245: The persist now lasts only until the first timeout, at which time ! 246: a packet is sent of the largest size allowed by the window. ! 247: If this packet is not acknowledged, the output routine must begin retransmission ! 248: rather than returning to the persist state. ! 249: .PP ! 250: Another change related to the send policy is a strategy designed to minimize ! 251: the number of small packets outstanding on slow links. ! 252: This is an implementation of an algorithm proposed by John Nagle ! 253: in RFC-896. ! 254: The algorithm is very simple: ! 255: when there is outstanding, unacknowledged data pending ! 256: on a connection, new data are not sent unless they fill a maximum-sized ! 257: segment. ! 258: This allows bulk data transfers to proceed, ! 259: but causes small-packet traffic such as remote login to bundle together ! 260: data received during a single round-trip time. ! 261: On high-bandwidth, low-delay networks such as a local Ethernet, ! 262: this change seldom causes delay, but over slow links or across the Internet, ! 263: the number of small packets can be reduced considerably. ! 264: This algorithm does interact poorly with one type of usage, however, ! 265: as demonstrated by the X window system. ! 266: When small packets are sent in a stream, such as when doing rubber-banding ! 267: to position a new window, and when no echo or other acknowledgement ! 268: is being received from the other end of the connection, ! 269: the round-trip delay becomes as large as the delayed-acknowledgement timer ! 270: on the remote end. ! 271: For such clients, a TCP option may be set with \fIsetsockopt\fP ! 272: to defeat this part of the send policy. ! 273: .PP ! 274: For bulk-data transfers, the largest single change to improve performance ! 275: is to increase the size of the send and receive buffers. ! 276: The default buffer size in 4.3BSD is 4096 bytes, double the value in 4.2BSD. ! 277: These values allow more outstanding data and reduce the amount of time ! 278: waiting for a window update from the receiver. ! 279: They also improve the utility of the delayed-acknowledgement strategy. ! 280: The delayed acknowledgment strategy withholds acknowledgements ! 281: until a window update would uncover at least 35% of the window; ! 282: in 4.2BSD, with 1024-byte packets on an Ethernet and 2048-byte windows, ! 283: this took only a single packet. ! 284: With 4096-byte windows, up to 50% of the acknowledgements may be avoided. ! 285: .PP ! 286: The use of larger buffers might cause problems when bulk-data transfers ! 287: must traverse several networks and gateways with limited buffering capacity. ! 288: The source-quench ICMP message was provided to allow gateways in such ! 289: circumstances to cause source hosts to slow their rate of packet injection ! 290: into the network. ! 291: While 4.2BSD ignored such messages, the 4.3BSD TCP includes a mechanism ! 292: for throttling back the sender when a source quench is received. ! 293: This is done by creating an artificially small window (one which is 80% ! 294: of the outstanding data at the time the quench is received, but no less than ! 295: one segment). ! 296: This artificial congestion window is slowly opened as acknowledgements ! 297: are received. ! 298: The result under most circumstances is a slow fluctuation around the buffering ! 299: limit of the intermediate gateways, depending on the other traffic flowing ! 300: at the same time. ! 301: .PP ! 302: A final set of changes designed to improve network throughput ! 303: concerns the retransmission policy. ! 304: The retransmission timer is set according to the current round-trip ! 305: time estimate. ! 306: Unfortunately, the round-trip timing code in 4.2BSD had several bugs ! 307: which caused retransmissions to begin much too early. ! 308: These bugs in round trip timing have been corrected. ! 309: Also, the retransmission code has been tuned, using a faster ! 310: backoff after the first retransmission. ! 311: On an initial connection request where there is no round-trip time estimate, ! 312: a much more conservative policy is used. ! 313: When a slow link intervenes between the sender and the destination, ! 314: this policy avoids queuing large numbers of retransmitted connection requests ! 315: before a reply can be received. It also avoids saturation when ! 316: the destination host ! 317: is down or nonexistent. ! 318: During a connection, when the retransmission timer expires, ! 319: only a single packet is sent. ! 320: When only a single packet has been lost, this avoids resending ! 321: data that was successfully received; ! 322: when a host has gone down or become unreachable, it avoids sending ! 323: multiple packets at each timeout. ! 324: Once another acknowledgement is received, the transmission policy ! 325: returns to normal. ! 326: .PP ! 327: 4.2BSD offered a maximum receive segment size of 1024 for all connections, ! 328: and accepted such offers whenever made. ! 329: However, that size was especially poor for the Arpanet ! 330: and other 1822-based IMP networks (sorry, make that PSN networks) ! 331: where the maximum packet size is 1007 bytes. ! 332: This was compounded by a bug in the LH/DH driver that did not allow ! 333: space for an end-of-packet bit in the receive buffer, ! 334: and thus maximum size packets that were received were split across buffers. ! 335: This, in turn, aggravated a hardware ! 336: problem causing small packets following a segmented packet to be concatenated ! 337: with the previous packet. ! 338: The result of this set of conditions was that performance across ! 339: the Arpanet was sometimes abominably slow. ! 340: The maximum size segment selected by 4.3BSD is chosen according ! 341: to the destination and the interface to be used. ! 342: The segment size chosen is somewhat less than the maximum transmission unit ! 343: of the outgoing interface. ! 344: If the destination is not local, ! 345: the segment size is a convenient small size near ! 346: the default maximum size (512 bytes). ! 347: This value is both the maximum segment size ! 348: offered to the sender by the receive side, ! 349: and the maximum size segment that will be sent. ! 350: Of course, the send size is also limited ! 351: to be no more than the receiver has indicated it is willing to receive. ! 352: .PP ! 353: The initial sequence number prototype for TCP is now ! 354: incremented much more quickly; this has exposed two bugs. ! 355: Both the window-update receiving code and the urgent data receiving ! 356: code compared sequence numbers to 0 the first time they were called ! 357: on a connection. This fails if the initial sequence number has ! 358: wrapped around to negative numbers. Both are now initialized ! 359: when the connection is set up. This still remains a problem ! 360: in maintaining compatibility with 4.2BSD systems; ! 361: thus an option, TCP_COMPAT_42, was added to avoid using such sequence numbers ! 362: until 4.2 systems have been upgraded. ! 363: .PP ! 364: Additional changes in TCP are listed by source file: ! 365: .XP tcp_input.c ! 366: The common case of TCP data input, the arrival of the next ! 367: expected data segment with an empty reassembly queue, was made ! 368: into a simplified macro for efficiency. ! 369: \fITcp_input\fP was modified to know when it needed to call the output side, ! 370: reducing unnecessary tests for most acknowledgement-only packets. ! 371: The receive window size calculation on input was modified ! 372: to avoid shrinking the offered window; ! 373: this change was needed due to a change in input data ! 374: packaging by the link layer. ! 375: A bug in handling TCP packets received with both data and options ! 376: (that are not supposed to be used) has been corrected. ! 377: If data is received on a connection after the process has closed, ! 378: the other end is sent a reset, preventing connections from ! 379: hanging in CLOSE_WAIT on one end and FIN_WAIT_2 on the other. ! 380: (4.2BSD contained code to do this, but it was never executed ! 381: because such input packets had already been dropped ! 382: as being outside of the receive window.) ! 383: A timer is now started upon entering ! 384: FIN_WAIT_2 state if the local user has closed, closing the connection ! 385: if the final FIN is not received within a reasonable time. ! 386: Half-open connections are now reset more reliably; there were circumstances ! 387: under which one end could be rebooted, and new connection requests ! 388: that used the same port number might not receive a reset. ! 389: The urgent-data code was modified to remember which data had ! 390: already been read by the user, avoiding possible confusion if two ! 391: urgent-data signals were received close together. ! 392: Another change was made specifically for connections with a TAC. ! 393: The TAC doesn't fill in the window field on its initial packet (SYN), ! 394: and the apparent window is random. ! 395: There is some question as to the validity of the window field ! 396: if the packet does not have ACK set, ! 397: and therefore TCP was changed to ignore the window information ! 398: on those packets. ! 399: .XP tcp_output.c ! 400: The advertised window is never allowed to shrink, ! 401: in correspondence with the earlier change in the input handler. ! 402: The retransmit code was changed to check for shrinking windows, ! 403: updating the connection state rather than timing out ! 404: while waiting for acknowledgement. ! 405: The modifications to the send policy described above are largely ! 406: within this file. ! 407: .XP tcp_timer.c ! 408: The timer routines were changed to allow a longer wait for acknowledgements. ! 409: (TCP would generally time out before the routing protocol ! 410: had changed routes.) ! 411: .NH 2 ! 412: UDP ! 413: .PP ! 414: An error in the checksumming of output UDP packets was corrected. ! 415: Checksums are now checked by default, unless the COMPAT_42 configuration ! 416: option is specified; it is provided to allow communication with the 4.2BSD UDP ! 417: implementation, which generates incorrect checksums. ! 418: When UDP datagrams are received for a port at which no process is listening, ! 419: ICMP unreachable messages are sent in response unless the input packet ! 420: was a broadcast. ! 421: The size of the receive buffer was increased, as several large datagrams ! 422: and their attached addresses could otherwise fill the buffer. ! 423: The time-to-live of output datagrams was reduced from 255 ! 424: to 30. ! 425: UDP uses its own \fIctlinput\fP routine for handling of ICMP errors, ! 426: so that errors may be reported to the sender without closing the socket. ! 427: .NH 2 ! 428: Address Resolution Protocol ! 429: .PP ! 430: The address resolution protocol has been generalized somewhat. ! 431: It was specific for IP on 10\ Mb/s Ethernet; it now handles multiple ! 432: protocols on 10 Mb/s Ethernet and could easily be adapted to other ! 433: hardware as well. ! 434: This change was made while adding ARP resolution ! 435: of trailer protocol addresses. ! 436: Hosts desiring to receive trailer ! 437: encapsulations must now indicate that by the use of ARP. This allows ! 438: trailers to be used between cooperating 4.3 machines while using ! 439: non-trailer encapsulations with other hosts. ! 440: The negotiation need not be symmetrical: a VAX may request trailers, ! 441: for example, and a SUN may note this and send trailer packets ! 442: to the VAX without itself requesting trailers. ! 443: This change requires modifications to the 10 Mb/s Ethernet drivers, ! 444: which must provide an additional argument to \fIarpresolve\fP, ! 445: a pointer for the additional return value indicating whether trailer ! 446: encapsulations may be sent. ! 447: With this change, the IFF_NOTRAILERS flag on each interface is interpreted ! 448: to mean that trailers should not be requested. ! 449: Modifications to ARP from SUN Microsystems add \fIioctl\fP operations ! 450: to examine and modify entries in the ARP address translation table, ! 451: and to allow ARP translations to be ``published.'' ! 452: When future requests are received for Ethernet address translations, ! 453: if the translation is in the table and is marked as published, ! 454: they will be answered for that host. ! 455: Those modifications superceded the ``oldmap'' algorithmic translation ! 456: from IP addresses, which has been removed. ! 457: Packets are not forwarded to the loopback interface if it is not marked ! 458: up, and a bug causing an mbuf to be freed twice ! 459: if the loopback output fails was corrected. ! 460: ARP complains if a host lists the broadcast address as its Ethernet address. ! 461: The ARP tables were enlarged to reflect larger network configurations ! 462: now in use. ! 463: A new function for use in driver messages, \fIether_sprintf\fP, ! 464: formats a 48-bit Ethernet address and returns a pointer to the resulting string. ! 465: .NH 2 ! 466: IMP support ! 467: .PP ! 468: The support facilities for connections to an 1822 (or X.25) IMP port ! 469: (\fB/sys/netimp\fP) ! 470: have had several bug fixes and one extension. ! 471: Unit numbers are now checked more carefully during autoconfiguration. ! 472: Code from BRL was installed to support class B and C networks. ! 473: Error packets received from the IMP such as Host Dead are queued ! 474: in the interrupt handler for reprocessing from a software interrupt, ! 475: avoiding state transitions in the protocols at priorities above \fIsplnet\fP. ! 476: The host-dead timer is no longer restarted when attempting new output, ! 477: as a persistent sender could otherwise prevent new output from being attempted ! 478: once a host was reported down. ! 479: The network number is always taken from the address ! 480: configured for the interface at boot time; ! 481: network 10 is no longer assumed. ! 482: A timer is used to prevent blocking if RFNM messages from the IMP are lost. ! 483: A race was fixed when freeing mbufs containing host table entries, ! 484: as the mbuf had been used after it was freed.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.