To: stik-beta-testers@list.zetnet.co.uk
From: dlanor@oden.se (Ronald Andersson)
Organization: Atari
Subject: Re: Question about CNgetinfo under STiNG
X-Mailer: NEWSie Version 0.94 (Atari)

>On Thu, 25 Mar 1999, Ronald Andersson wrote:
>
----- snip ----- re: local IP used by connection must match call to server
>> 
>> We can't possibly know which IP address will be used until it happens.
>> Nor should we need to know it.
>
>	Well this isn't entirely true.  I wouldn't call a lack of a
>standard networking feature unproblematic.

When a single machine has multiple IP addresses, as all real networking
machines do have, then it is no part of standard networking to know in
advance which of those addresses a client will use to access a server.

That would require telepathy and/or precognition rather than networking. :-)


>  It really doesn't matter too much to me.  It works in the standard
>way under STiK and since that's what I use...  I'll just have to go
>the route of lp and report that some programs I port just aren't
>compatible with STiNG.

You know as well as I do that when the original STiK specs were created
there existed no servers at all for STiK, so please don't talk of the
'standard way' as if it was a long established and much used standard
for server programming.  AFAIK no server program ever used it.

Originally the only use made of listening connections was in clients
that expected a 'callback' connection from a single known remote, and
that alone is why the original spec was then sufficient.

Real servers must expect to be called from an unknown number of
remotes, some of which may be on a local net while others are on
remote networks (ie: Internet).  This means that different calls
will access the same server under different IP addresses, and so
the local IP used for connections of such servers will not be
definite until the connection is fully established at arrival
of the first packet from a client.

This is NOT specific to STinG, but to any TCP/IP stack that allows
a listening connection/socket to accept packets addressed to any
of the IP addresses belonging to the machine where the server runs.


Naturally it is possible to limit that ability, as would be quite
appropriate for clients of the kind mentioned, by opening some
listening connection in a mode that does NOT allow more than one
IP to be used, at either end of the connection.  This however
does require using an extended TCP_open mode, since the old one
does not allow for opening fully defined listening sockets.

STinG does allow such TCP_open calls to be made, as is clearly
described in the programming section of the STinG.HYP document.
That extended mode is the most appropriate one for use by any
clients that expect a call from a single known remote, but in
such cases an even simpler method is available, which I think
you will prefer since it does not use any STinG-specific modes.

Such clients normally need this kind of operation at a time when
they already have another (fully established) connection to the
same remote machine that they want the new connection for. Then
the easiest way to gain compatibility is to simply use the same
local IP address for the new connection as was used for the old
one.

That can easiest be done by using the traditional STiK TCP_open
mode for the new connection, and then rather than getting the
IP address from a CNgetinfo call for the new connection, get it
from a similar call for the old connection.  Since that one is
already fully established, its local IP address is available.

This will work both for STiK and for STinG, since the new packets
from the same remote will normally use exactly the same route.
That will solve all problems of compatibility with single-machine
STinG setups, and will also work on multi-machine STinG LANs for
the machine connected to the Modem (but not using Masquerade.Stx).

Fully masqueraded compatibility is not your problem, but mine,
yet I do promise to make future masquerading work in such a
way that the method described above will then work for all the
machines on a STinG LAN.

So here you have a very simple and 100% STiK-compatible method
to gain full compatibility at once with the large majority of
STinG users, with compatibility to _all_ of them being promised
for the future (once I fix high-level protocol masquerading).
That is the best I can do for you...

This method has been described before, but perhaps you (and lp)
were distracted from it somehow, so you missed its significance.
I trust you have noted it now at any rate, and that you will also
inform lonny about it, since I am unsure whether he still reads
this list.


----- snip ----- re: local socket mostly not needed before traffic
>
>	Lets see active ftp transfers, dcc ... realy any situation where
>the remote connection requests this information in the first packet.  It's
>not entirely an uncommon practice.

These are precisely the kind of special client cases that are best handled
by the method described further above.  So they are no problem anymore...


----- snip ----- re: what kind of changes in STinG TCP do you want ?
>
>	I don't see how I can explain any better.  I'm not entirely sure
>what the problem is with this idea and STiNG.

The entire problem is that STinG is a multiport TCP/IP stack with LAN
capability, whereas STiK is a single-port stack where only one single
local IP at at time can exist. This has led to inflexible assumptions
about the use of that local IP address in the original STiK specs.

As soon as we have more than one local IP address, those old specs
become insufficient and must be extended, which is one of the forcing
reasons behind many of the differencies of STinG from STiK. Those are
not arbitrary or unnecessary, but needed for proper functionality in
the multi-port TCP/IP environment STinG implements.

That is why I and Peter have rejected some suggestions of 'full' STiK
compliance in a few things, because that would not be possible to
implement without reducing STinG to a single-port stack again. In all
other cases I myself naturally favor full compatibility, since that
is the major strength of the STiK-related TCP/IP stack family, which
allows a large number of clients to run with any of several related
stacks.  (STiK, STinG, GlueSTiK, (any more ?))  That is why all of
these stacks are still viable, as they might not be if each needed
separately produced clients. This compatibility _must_ be preserved.


---- snip ----- re: your 'nasty cold'
>
>	10 days of antibiotics and I'm almost my old self again :)

I'm glad to hear it.

