On Thu, 7 Sep 1995 11:31:35 CDT Marty Hoag <[log in to unmask]> said:
>1. What is a good setting for the number of hops allowed? I think
> sendmail defaults to 17 these days.
I think this dates back to the 1980s, anyway it is ridiculously low for
today's network. About 4 years ago a lot of TCP/IP products had to be
changed to support a TTL larger than 25-30, which had been deemed to be
an "impossible hop count" when the software was written. I think we're
going to see just the same argument now:
a. People with the hardcoded max TTL of 25-30 claiming that it made no
sense at all to want to reach people more than 25-30 hops away.
b. Users not caring about the finer points of network topology and noting
that on the XXX they can reach their destination but on the YYY it
doesn't work (substitute brand names as appropriate).
c. People on the far end of a 20-odd network access point not having much
of an option in the matter and trying to argue with the people in (a),
unsuccessfully.
Eventually they all upped the limit and everyone was happy.
>2. Is there any way to add an option to LOCAL SYSVARS to make our local
> unspecified header default SHORTHDR? If not, can that be added?
Currently that isn't possible. An option could be added to make SHORTHDR
the default value for new subscribers. Technically the problem is that
the old coding scheme used one byte per option, with space being
"unspecified" and internally mapped to some hardcoded value, whereas the
new coding scheme uses one bit per option, so there is no "unspecified"
setting. The old scheme took up too much space and was error-prone (each
"user" of option X had to interpret the various possible values for the
one-byte code, and in particular determine the meaning of "unspecified",
and sometimes there were slight differences leading to inconsistent
behaviour). In a first stage, all this logic was centralized so that the
options were decoded by a single piece of code (and the meaning of
"unspecified" determined similarly). This solved the consistency problem,
but it was SLOW with large lists, because each option had to be decoded
regardless of which were going to be used, and in some cases there were a
lot of tests to make to determine the "unspecified" default. And of
course there was the problem that each option took up at least a byte,
and the list files would have to be reformatted every time a new option
was added (as opposed to every 31 options). Basically, the old scheme was
optimized for REXX code, the new one for compiled code.
All in all the problem with SHORTHDR is that the people who wanted it
killed here and now were VERY vocal (many threatened to stop paying for
the software if this change wasn't made), whereas people who did not want
the change hardly said anything. So, we thought no one really minded the
change, given the existence of "Default-Options=" and all that, and acted
accordingly. If we'd known there were many people opposed to the change,
we could have added an option to save the "unspecified" state of the
header flag and all sorts of other things, but now it's too late because
the one-way conversion has been made.
Eric
|
