MacTCP 2.0.6 Update Name: MacTCP 2.0.4 to 2.0.6 Patch, MacTCP Admin 2.0.6 Patch, Read Me, Release Notes Version: 2.0.6 Date Released: 11/28/94 Brief Description: See Below Read Me for MacTCP 2.0.6 Patches Copyright ©1994, Apple Computer, Inc. All rights reserved. November 22, 1994 What Is This For? =============== The applications: "MacTCP 2.0.4 to 2.0.6 Patch" and "MacTCP Admin 2.0.6 Patch" are ResCompare resource patching applications. Applying the appropriate patch to a COPY OF YOUR ORIGINAL ("virgin") MacTCP or MacTCP Admin control panel will upgrade your copy to version 2.0.6. What Can Be Upgraded? ==================== All licensed copies of MacTCP 2.0.4 can be upgraded. For users of earlier 2.x versions (2.0 and 2.0.2. those must first be updated to version 2.0.4 before updating to version 2.0.6) What Cannot Be Upgraded? ======================= Any other version of MacTCP 2.x (i.e, 2.0.1... 2.0.3... 2.0.5É), any MacTCP alpha, beta, or development version, or any version of MacTCP v1.x may not be upgraded. What's The Difference? ==================== The changes between MacTCP 2.0.4 and MacTCP 2.0.6 are described in the Release Notes document. MacTCP 2.0.5 was an interim release, only distributed internally at Apple. -------------------------------------------------------------------------- Release Notes for MacTCP 2.0.6 Copyright ©1994, Apple Computer, Inc. All rights reserved. November 22, 1994 MacTCP version 2.0.6 is an update release. MacTCP version 2.0.5 was only released internal to Apple. MacTCP 2.0.6 contains the following improvements over MacTCP 2.0.4 and earlier versions: Domain Name Resolver: --------------------- ¥ Inbound Domain Name Server replies are now processed one Resource Record (RR) at a time in order to avoid exhausting the DNR's limited pool of memory. This allows 2.0.6 to swallow the most verbose BIND 4.9.2/3 ADDAUTH PTR replies without encountering an out-of-memory error condition. ¥ The DNR now only caches A and CNAME RRs from the Answer section. NS RRs from Authority and A RRs from Additional are used to recursively follow-up references if that's necessary, but they are not stored. This greatly reduces the demand placed on the DNR's limited memory pool. It also transforms the DNR almost totally into a Stub Resolver (see RFCs 1034 and 1035). As a side effect, each new query starts off with only the name server information originally configured in the control panel or from a server. This makes the choice of which server(s) to contact, and the order in which they will be contacted, much more determinate and under the control of the configuring administrator. ¥ Several small memory leaks have been fixed, including a corner case in MacTCP 2.0.4 in which a block of memory could be freed twice, causing indeterminate problems later on. ¥ The DNR is now fully up to date in terms of permitted and forbidden syntax for domain names. ¥ Domain name syntax checking has been extended to cover MXINFO and HINFO requests; previously only A requests (String To Address) went through this check. Performance: ------------ ¥ Previous versions of MacTCP kept track of retransmission timers on a per segment basis. If 4 successive segments were dropped due to congestion at a gateway, the retransmission of each one would require a separate time-out, and each would force an additional exponential back-off. Because of this, retransmission time-outs sometimes became excessively long. In MacTCP 2.0.6, retransmission of a group of segments does not result in further exponential back-offs. ¥ Under certain conditions, MacTCP 2.0.6 will assume that a duplicate ack implies that retransmission of data will be required, and will expedite the retransmission process. This often results in much shorter retransmission delays when MacTCP is sending data. Configuration: ------------- ¥ Previous versions of MacTCP checked both the source and destination port field in Bootp configuration responses, and did not accept the response unless the source port was 67 (Bootp Server) and the destination port was 68 (Bootp Client). Because the Bootp protocol permits Bootp Relay Agents (which are Clients) to relay configuration packets from their own Client port address, MacTCP failed to accept valid Bootp responses passing through Bootp Relay Agents that implemented this feature. MacTCP 2.0.6 now only checks the destination port for validity. ¥ When configuring via Bootp, previous versions of MacTCP saved only the last Domain Name Server returned in a Bootp reply. In cases where only one DNS server was returned, this didn't matter. When more than one server was returned, the one saved (the last one) was usually the least desirable server. 2.0.6 is still limited by architectural constraints to using a single Bootp-configured DNS server, but it now saves the first one returned - that is, the "best" or most desirable server in the list. ¥ Previous versions contained a bug in the Bootp configuration code for the processing of the Default Gateway option that could have led the DNR to corrupt any portions of a Bootp reply following that option.