Received: by maskin (mbox dlanor)
 (with Cubic Circle's cucipop (v1.31 1998/05/13) Sat Apr  3 16:17:50 1999)
X-From_: owner-stik-beta-testers@list.zetnet.co.uk Sat Apr  3 15:46:02 1999
Received: (from uucp@localhost)
	by maskin.ettnet.se (8.9.1a/8.8.8) id PAA19230
	for <dlanor@oden.se>; Sat, 3 Apr 1999 15:46:02 +0200 (MET DST)
Received: from UNKNOWN(194.247.47.34), claiming to be "spodden.zetnet.co.uk"
 via SMTP by maskin, id smtpdAAAa004gO; Sat Apr  3 15:45:58 1999
Received: from majordom by spodden.zetnet.co.uk with local (Exim 2.05 #1 (Debian))
	id 10TQh6-0007pD-00; Sat, 3 Apr 1999 14:42:40 +0100
Received: from maskin.oden.se (maskin.ettnet.se) [193.220.120.1] 
	by spodden.zetnet.co.uk with esmtp (Exim 2.05 #1 (Debian))
	id 10TQh4-0007p4-00; Sat, 3 Apr 1999 14:42:39 +0100
Received: (from uucp@localhost)
	by maskin.ettnet.se (8.9.1a/8.8.8) id PAA19137
	for <stik-beta-testers@list.zetnet.co.uk>; Sat, 3 Apr 1999 15:42:21 +0200 (MET DST)
Date: Sat, 3 Apr 1999 15:42:21 +0200 (MET DST)
Message-Id: <199904031342.PAA19137@maskin.ettnet.se>
Received: from UNKNOWN(193.220.122.7), claiming to be "oden.se"
 via SMTP by maskin, id smtpdAAAa004ey; Sat Apr  3 15:42:14 1999
To: stik-beta-testers@list.zetnet.co.uk
From: dlanor@oden.se (Ronald Andersson)
Organization: Atari
Subject: Re: RE: Question about CNgetinfo under STiNG
X-Mailer: NEWSie Version 0.94 (Atari)
X-Sender: POPwatch v2.91 (Atari)
Sender: owner-stik-beta-testers@list.zetnet.co.uk
X-Loop: stik-beta-testers@list.zetnet.co.uk
Precedence: bulk
Reply-To: stik-beta-testers@list.zetnet.co.uk

>Ronald wrote:
>
----- snip ----- re: not knowing what IP incoming calls will use
>
Steven wrote:
>
>Why? The router knows in advance how to route to a particular address from 
>the ROUTE.TAB file and this can easily be looked up in to find out the IP 
>address to fill in the field.

Certainly.  If the TCP_open call specifies the remote IP, then we can
indeed calculate the route.  The problem is that the standard TCP_open
call for listening connections in the STiK interface can NOT specify
any information about the remote at all.  The only thing that can be
specified for such a connection is the local port number...

Specifying an IP for the remote machine is only possible for active
connections, since a listening connection is selected by specifying
a remote IP of zero, which also causes the remote port argument to
be reinterpreted as being the local port for 'listening'.

So what Dan wants me to do is to calculate the IP to which an incoming
call will be addressed, without having any other clue than the local
port number.  This does not supply any routing information at all,
and I still do not think it can be done then, except of course for
a single-port stack where the local IP is constant (while online).

If you do not agree that it is impossible, then please explain to me
the method of finding the IP under these circumstances.


But there are other solutions, giving full compatibility:

1:  He can use the extended STinG TCP_open mode that allows him
    to specify remote data for listening connections.  But I know
    he does not want to use any STinG-specific stuff, so I assume
    he won't like this alternative.

2:  For clients that need to pass an IP address to a server, they
    can just use the IP returned by CNgetinfo for the connection
    they already have to that server.  This would be compatible
    with both STiK and STinG, as well as using no extended mode
    whatever, just standard STiK calls.

I presented both these alternatives in my earlier mail too, yet
neither you nor Dan (in his reply) consider these worth mentioning,
making it obvious that they won't be used.  Please tell me why not.

If my alternative solutions, which would work, are so horribly
bad in your opinion, then please tell me a good solution instead.
If there is one I would really like to learn about it.


----- snip ----- re: limitations of STiK specifications
>>
>>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 isn't true

What you say below is merely a different way of stating some things
that I also said in other parts of my mail, but it does not affect
the truth that a real server must be able to accept calls from more
than one source and through more than one route.  And that was the
main point of my statement.


>as an ftp client, irc client must all know their own IP 
>address to function correctly as they pass the address of an open listen 
>socket on their machine to the other end of the connection.

Those are some of the special cases for which I used the term
'callback connection' in my mail.  There are other such protocols
too of course.


>Under STiNG they can't do this, yet can under any TCP/IP stack.

Of course they can do it under STinG !  Whoever said anything else ?

There are several FTP clients that function under STinG, using either
PASV or PORT commands.  The only real problem is that the Masquerade
does not support high-level masking yet, but that is coming too.

No, the problem is not that it can't be done with STinG, but that it
can't be done exactly the same way as for a single-port stack like
STiK (single IP variable), which is what Dan seems to be demanding.


-------------------------------------------------------------------------
Regards:  Ronald Andersson                   mailto:dlanor@ettnet.se
http://www.ettnet.se/~dlanor/                mailto:dlanor@oden.se
http://dlanor.atari.org/                     mailto:ra@cgiforme.com
-------------------------------------------------------------------------

---------------------------------------------------------------------------
To unsubscribe from this list, e-mail Majordomo@list.zetnet.co.uk
with the body of the message containing "unsubscribe Stik-Beta-Testers"
---------------------------------------------------------------------------

.
