To: perot@pallas.amp.uni-hannover.de
Subject: TCP patch for STiK 2


Today I have been thinking a lot about Intranetting with STiK 2, and on the
need for various server modules (later of course) to make this more useful.
In one mail to the list I suggested that a pseudo port "Internal" be defined,
constituting a pseudo network for servers, so each can have it's own IP number.

This set me thinking even further on the subject of pseudo ports, and I think
I have come up with a way to make use of the TCP routines in STiK 1 for STiK 2,
without having to wait for Dan to deliver a module (if ever).

One problem is that STiK 2 must have an identical cookie as STiK 1 had, and two
such cookies can not coexist peacefully on the system.  This is easily solved
by making new copies of STIKTSR.PRG and STIK.ACC, renamed to ST1KTSR.PRG and
ST1K.ACC .  We then use a file editor to change each "STiK" sequence in those
files to "ST1K".  That solves coexistence completely.  Next we have to make
them work together, as follows.

We need a dummy TCP.STX, which simply sends each client TCP command on to the
old ST1K interface and vice versa.  It should also remember the IP number of
the client port for each channel, and translate between the multiple local
numbers of STiK 2 to the single local number of STiK 1.  Thus we already have
IP masquerading for TCP.

At boot, this module searches for the ST1K cookie interface, and refuses to be
installed if not present.  Otherwise it prepares a pointer to a routine which
will initialize ST1K.ACC in much the same way that your STiK 1 dialer does,
but without actually dialling, or transmitting anything at all.  It should
however tell ST1K.ACC the IP number used in the last STiK 2 dialling, so ST1K
has a legal way of talking to Internet.  At the end of that init routine the
pointer should be repatched to point to a function which handles the passing
of calls to ST1K, whereafter the init function should call that function.

So at the first TCP-related client call, the init routine will be called before
the call is passed to ST1K, but on later calls this does not happen.  Then when
the dial-up connection is terminated we need a way for the pointer to be reset
so it again points to the init routine, but that should not be hard to arrange.

Another dummy module "RESOLVER.STX" could do the same job for resolving, by
giving access to the resolver of ST1K, until Martin Mitchell delivers his.

This might mean until you do it I'm afraid, unless Dan and Martin come across.


I think the above is a complete solution for how to get STiK 2 to work with
TCP connections to the real Internet, though it does very little for the
local Intranet.  From the moment this is implemented STiK 2 could be used in
place of STiK 1 for all traffic possible today, plus the new use of allowing
clients to access Internet from any machine on the local Intranet.  Though
other machines than the one having the modem must use direct IP numbers,
since they cannot call the resolver.


Actually I have thought of a method to do fully local TCP as well, but I do
not find it reasonable to implement this due to the complexity of it.  It
would waste time that would be better invested in making a proper TCP STX.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
