Very Computer

I've just rebuilt KA9Q with gcc2.1.1a.  The primary reason is to get
out a version where directory operations use the new system
facilities, in preparation for new file system types.  I've also made
a change that improves interactive response with compressed SLIP when
there are errors.

Anyway, the question is what form to distribute the binaries in.
Normally I'd build a static linked version with the current libc.  But
I wondered if we were now adopting a convention of distributing
binaries as .a files.  This would let people relink with their version
of libc, so they can share the image.  However it also forces people
to link the binary.  It's less convenient than giving them a
ready-to-run executable.

A question: I'm thinking of adding some provision to let you define
multiple packet sizes.  I find that under the test image of 0.96a, I
get really good response using an MSS of 64.  At least on a 9600 bps
line with compressed SLIP, this almost completely eliminates the
jerkiness you normally get under SLIP.  However this is probably too
small for FTP'ing stuff, particularly over the Internet.  I'm thinking
of allowing you to define more than one set of mss and window.  The
question is how to label them.  Should I associate an mss and window
with applications, e.g. telnet and ftp?  Or does it make more sense to
specify one set for things on the same network and another for
external sites?  Either would work in my case.

Finally, has anybody given thought to how X is going to talk to other
systems?  Is there progress on a real kernel-based TCP?  If not, do
any of the X implementors want to try a hack with KA9Q?  It wouldn't
be hard to turn KA9Q into a server.  The idea would be that the socket
emulation library, when it saw an IP or TCP open, would actually open
a pipe to KA9Q, telling KA9Q what address and port was desired.
Someone has already done this for KA9Q under BSD.  I don't think it
would be hard to implement.  However you'd be adding an extra process
activation (the KA9Q server) for each packet being sent to the real
application.  This is probably OK for SLIP, but it wouldn't be my
first choice for Ethernet.

| question is how to label them.  Should I associate an mss and window
| with applications, e.g. telnet and ftp?  Or does it make more sense to
        You could use IP port numbers; they're probably more available
at that layer. However, if you have a large ftp MSS, and you're doing
an ftp in parallel with a telnet, won't you see just as poor response
from the telnet?
        The BSD SLIP driver defaults to an mss of 296. Going between a
sparcstation and my PC (running 386bsd) there doesn't seem to be any
big problem, though it gets a bit slower when an ftp is going on the
priority queuing seems to help a lot.

| Finally, has anybody given thought to how X is going to talk to other
| systems?  Is there progress on a real kernel-based TCP?  If not, do
        I was just wondering that myself; I'm torn right now between
386BSD (with a working tcp layer, though some problems in the serial
drivers, and no X) and Linux (with no tcp layer, but working X).
Wouldn't it be fairly straightforward to just move the KA9Q code into
the kernel, strip out the application parts and moving the IP and TCP
level interfaces up to syscalls and file interfaces? (I haven't looked
at the KA9Q sources, nor at the recent Linux kernel sources.)

                                MIT Student Information Processing Board