--flr e-mail:firstname.lastname@example.org voice:(313)764-1656
URL: http://www.engin.umich.edu/~friscolr/ fax: (313)995-4370
come read the quickcam review!
---------- Forwarded message ----------
Date: Thu, 24 Nov 1994 02:12:34 -0600
From: Bill Detmer <email@example.com>
To: Multiple recipients of list <firstname.lastname@example.org>
Subject: MacTCP 2.0.4 --> 2.0.6 patch now available
=46or those of you with the "infinite slow-down" MacTCP bug or DNR problems,
the patch for MacTCP is now available. According to Garry Hornbuckle at
Apple, the patch will be available on the usual apple ftp sites in the next
few days. If you are desperate to get your hand on it, it is now available
by anonymous ftp from seeding.apple.com NOTE: you must perform the patch
on a VIRGIN copy of MacTCP 2.0.4 (ie, a copy from your installer disks, not
the MacTCP in your current system folder).
I'd be curious if this patch fixes some of the network problems MacHTTP
users are currently having. For me, the new version supports somewhat
better performance for programs such as Timbuktu Pro, but I still have the
problem that if I use FTP to GET a file from site A from site B I get 3000
bytes/sec transfer while if I PUT a file to site A from site B I only get
100 bytes/sec transfer. In addition, performance of my MacHTTP server
(http://dgim-www.ucsf.edu/) running on a Performa 636 over a T1 link is
still very poor.
Because I thought this MacTCP update might be of interest to many on this
list, I have appended the release notes to the end of this message.
| William M. Detmer |
| Information Systems Manager |
| Division of General Internal Medicine |
| University of California-San Francisco |
| email@example.com |
Release Notes for MacTCP 2.0.6
Copyright =A91994, 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
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
* 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.
* 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.