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 Fri, 2 Apr 1999, Ronald Andersson wrote:
>
----- snip ----- re: local IP used by connection must match call to server
----- snip ----- re: what you demand requires telepathy/prcognition
>
Dan wrote:
>
>	I cut most of your message, because it goes on with this basic
>false premise above.

The premise is not false, since your prime requirement has constantly
been that nothing other than normal STiK calls may be used, and that
even the way of using those must remain identical to your ways of
programming for STiK only.

This means that you expect STinG to solve a 'backwards route' given no
other info than the local port number.  AFAIK that is not possible.

That is why I suggested an alternative that would work equally well
with both STiK and STinG, while still not requiring that you use any
calls other than those existing in STiK.  The only difference from
the method you speak of is that the IP would be fetched from the
already open connection, since a 'callback' connection will have
to use the same IP.

Evidently you do not even consider that suggestion worth replying to...


> It's not true of BSD sockets, windows or the Mac.

If anyone insisted that they do it with only the information supplied
by the STiK TCP_open call, then it would be equally true of them.
But of course, no one would ever think of insisting on that for them.


>I would like to know what stacks it is true for other than STiNG.

I didn't mean any stack should have this handicap, not even STinG !
In fact that was my major point, which you seem to have missed.

What I meant was that given the information that you are willing to
pass (from what you have said so far, only a port number), any stack
would be unable to resolve the IP in the way that you want it.
(Including all those you mention.)


>If you create a socket under BSD sockets you have the information that
>I propose you put into STiNG.

If you create a socket under BSD sockets you also have to GIVE info to
the stack so as to enable it to deduce the route.  If you only specify
the local port number, which is your only suggestion so far, then the
connection must accept calls directed at all IP addresses on that
machine.  The local IP can not then be known until the socket has
achieved connection with a remote machine.

As I have described, the STinG TCP_open call already has extensions
that allow creating listening connections with specific remote IP, and
with those it would be easy to deduce the route through which incoming
calls must arrive.  Some slight changes might be needed to debug this
(since no clients use it yet), but it could be done by trivial effort.

This mode was one of the two alternatives I suggested in my last mail,
but it is evident that you have rejected this, since you do not speak
of it at all in your reply.


>It exists under STiK,

Sure, STiK has a single IP address, so it puts that as local IP for all
connections.  Routing simply does not exist, so it is never a problem.
Do you seriously believe this to be applicable to STinG...?


>and frankly to port ICQ to STiNG as well as STiK would be a nightmare
>bastardization of the code.

Why ?

The original ICQ implementations use stacks quite different from both
STiK and STinG.  A port to either one should make further port to the
other a quite simple task.


>It makes no sense why a standard function under any reasonable TCP/IP stack
>does not function under STiNG, and I have to hear how that's a lie.

I agree that standard functions under reasonable TCP/IP stacks should also
be available under STinG.  In fact I think they already are.  But you have
to remember that various stack use different APIs, so the specific functions
to be used varies with the stack.  And reasonable use means that one should
use those functions in ways adapted to the stack being programmed for.

The problem we have lies in that some STiK methods depend totally on the
single-port nature of STiK, and for those cases STinG has to use other
means.  These are mostly already implemented, but what help is that when
you insist that only original STiK functions must be used, and those
only as normally used by STiK clients.  That is not reasonable.

For example, the internal STinG method for finding the local IP suitable
for connecting to a given remote IP is to use PRTCL_get_parameters.

Here are some call examples to show you what I mean:

PRTCL_get_parameters (remote_IP, & local_IP, & connect->ttl, & connect->mtu);
PRTCL_get_parameters (remote_IP, & local_IP, NULL, NULL);

The first form is most appropriate for low level programs that intend to
construct an IP datagram on their own.  The second example is the kind
that could be used by a client needing to precalculate a local IP for
a future connection with the given remote.

If that local IP is then used in an extended TCP_open, then the IP will
also be accessible via CNgetinfo at once, so special cases need only be
used at opening of the connection and to get info for sending to server.
During actual traffic all usages could be identical to those of STiK.

One way of using this could be the following:
----- example start -----
if  (STinG_flag)    /* Test STinG flag set up by test at prog init */
{   rem_IP = CNgetinfo( FTP_ctrlconn )->address.rhost;
    PRTCL_get_parameters( rem_IP, &loc_IP, NULL, NULL );
    {   CAB FTP_datasock = { FTP_dataport, 0, rem_IP, loc_IP };
        FTP_dataconn = TCP_open((uint32)(&FTP_datasock),TCP_PASSIVE,0,bfsize);
    }   /* The above opens a connection listening only to expected caller */
}
else                /* Assume STiK methods if not STinG */
    FTP_dataconn = TCP_open( NULL, FTP_dataport, 0, bfsize );
loc_IP = CNgetinfo( FTP_dataconn )->address.lhost;
----- example end -----
As the last line shows, connection use can be identical from there on.

Another method would require a (very) small modification to TCP.STX
and would then simplify the above to this:
----- example start -----
if  (STinG_flag)    /* Test STinG flag set up by test at prog init */
{   rem_IP = CNgetinfo( FTP_ctrlconn )->address.rhost;
    CAB FTP_datasock = { FTP_dataport, 0, rem_IP, NULL };
    FTP_dataconn = TCP_open((uint32)(&FTP_datasock),TCP_PASSIVE,0,bfsize);
}   /* The above works like before, but eliminates PRTCL_get_parameters */
else
    FTP_dataconn = TCP_open( NULL, FTP_dataport, 0, bfsize );
loc_IP = CNgetinfo( FTP_dataconn )->address.lhost;
----- example end -----

But to be quite honest, the _simplest_ method for such clients is still
to use the local IP gotten from the already existing connection, because
that can be done identically for STiK and STinG, with identical results.

It could be done this easily:
----- example start -----
{   CIB *FTP_ctrl_cib = CNgetinfo( FTP_ctrlconn );
    FTP_dataconn = TCP_open( NULL, FTP_dataport, 0, bfsize);
    loc_IP = FTP_ctrl_cib->address.lhost;
}
----- example end -----

That's it.  No tests and no special cases.  Identical for STiK and STinG.
And it should work for all normal cases of routing.

But then, that was one of the suggestions in my last mail that you have
already rejected without comments, so I guess it's no use talking about
it now. (?)

I am (as always) open to suggestions and debate, but I don't think we
can get that going (in a positive way) by just cutting out seriously
intended suggestions without stating what was wrong with them.

I'm not saying that you shouldn't say I'm wrong, but only that when you
do so you should also tell me _why_ and try to suggest how it should be
done.

