jdd@allegra.UUCP (07/14/83)
More flames on 4.1c:
First, Mike O'Dell (ucbvax!mo) was right when he said that:
.... There is
an option which is supplied to the socket() call to allow addresss
rebinding exactly compliant with the semantics of TCP.
(I had said that this couldn't be done.) I had been confused because such
an option is \nowhere/ documented! (I finally discovered it when reading
through various system source and header files.) It is, of course, the
SO_REUSEADDR option (commented with a "(gag)" in socket.h).
\Now/, my problem is that there is no documentation for an "options"
argument to socket()! In the manual page, there are only three arguments to
socket(), none of which is a mask suitable for or-ing SO_REUSEADDR into.
On the other hand, every call to socket() in /usr/src/ucb/netser/*/* has
\four/ arguments, the fourth of which is zero! So I could try using the
fourth as an "options" field and see what happens....
On yet another hand, I have found a completely undocumented routine,
setsockopt(), which it would seem can be used to set SO_REUSEADDR on a
currently existing socket (some network services use it to set SO_KEEPALIVE,
for example). There are yet other interesting undocumented calls you can
find by reading the source, such as sockaddr(); these can come in handy
sometimes (but they would be handier if one knew what the arguments were).
Another topic: let's talk about multiplexed files. Well, there's not a lot
to say about them, because they've been taken out of 4.1c; unfortunately,
there's been nothing to replace them. My understanding is that the
replacement was to be portals and the like; portals had been planned for 4.2
but are definitely not in 4.1c (the code in the kernel reads approximately
as "portal() { }"), which is a pity; portals and their friends (like
wrappers) could easily provide a superset of what you can do with
multiplexed files, but what there is now is a definite subset.
Where does this matter? Well, let's consider telnet(1) and telnetd. Telnet
has all (well, most) of the standard echo-negotiation stuff built into it to
let the server side turn local echoing on and off. Telnetd, on the other
hand, uses 4.1c pty's for communication with the processes on the remote
machine, and there is \no way/ for it to catch ioctls and tell whether the
server-side processes want echoing on or off. Therefore, telnetd tells the
client (typically telnet) \never/ to echo locally, letting the server pty do
all the work itself. This is a poor substitute for what you'd like to be
able to do; not being able to catch ioctl's can be a big lose.
(Oh, and you should see it when telnet talks to a non-telnetd server that
does know enough to do proper echo negotiation. When telnet is in local
echo mode, which perhaps they didn't test since this never happens with
telnetd, it echos things like ^H and ^W and the like as "^H" and "^W" and
the like rather than \doing/ them: nice.)
An example of an offshoot from this: various people have asked whether
library routines could be written to simulate multiplexed files using the
more powerful 4.2 routines. Well, maybe, but it definitely can't be done
using the less powerful 4.1c routines.
(Of course, I could be wrong; it could be that all the right things are in
4.1c but just undocumented.)
Touching briefly on the Ethernet Address Recognition Protocol (ARP): while
ARP is definitely a great idea for configuring a network of 4.2 systems, it
is going to be a \big lose/ if there is no way around using it! In my
Laboratory, in addition to our 4.2 VAX systems, we are going to be
networking a bunch of "4.2" Sun systems, a number of 11/23's running UNET
software, some 4.1 VAXen running UNET for a while, a few Cadlinc
workstations running our own networking software, a couple of LISPM's
running Symbolics' idea of TCP/IP, maybe a laser printer running Ghod knows
what, and so forth: I \guarantee/ that most of these will never have heard
of ARP.
Trying to hook this much stuff together is where \standards/ become handy,
and saying that ARP \ought/ to be a standard because it's \so handy/, and
should therefore be required on \all/ hosts on a network, seems simplistic.
There should at least be an ioctl available to set a 4.2 host's idea of the
mapping for an individual machine; otherwise, everybody's going to have to
hack it in themselves.
And speaking of "4.2" from Sun: does anyone know if it is really just 4.1c
or whether it has some of the decent 4.2 things added?
More later.
Cheers,
John ("Learning Through Doing") DeTreville
Bell Labs, Murray Hill