To: stik@ON-Luebeck.DE
Subject: Re: [4] STIK: Important inquiry, pleas                                          


On Sat, 4 Jan 1997 13:38:56  Peter Rottengatter <perot wrote: 
>
>On Fri, 3 Jan 1997, Ronald Andersson wrote:
>>
----- snip ----- re: local IP entry in CIB structure
>> 
>> Well, then the most obvious way to do it is of course to keep them in a common
>> structure, like you suggested.  Especially when the structure already exists,
>> needing only the addition of one more element.
>
>There are some other, more obvious violations of RFC793 in the STiK TCP 
>API. However, I fear there is no way to properly cure some of them without
>changing the definition of some functions, most notably TCP_open and 
>TCP_close. Maybe we can live with some of them, and we should prefer to 
>keep the API. Some of them can be cured in a transparent way, but I guess 
>first an attempt to port the TCP to the new STiK structure should be 
>finished, then those changes can be applied.

Definitely true.  Once we have a functional replacement for the old STiK, we
can simply add new API functions without losing any compatibility to the old.


----- snip ----- re: compatibility to old 'local-IP' methods
>> >
>> >Actually that would be a consistent way to provide for the client_ip 
>> >entry in the CONFIG structure, which is AFAIK the only entry the dev-kit 
>> >explicitly recommends to use. Maybe that's the way to go. But it will 
>> >create the situation that some old programs will continue to work on some 
>> >people machines, but not on others (both cases with new STiK).
>> 
>> No, not necessarily.  Ports must always be opened in some way before use, and
>> as long as the port the client needs to use is the last port opened it should
>> work.
>
>But the last is not the case if the client is executed by a machine that 
>has more than one network interface, and the TCP connection goes via an 
>interface that is not the most recently opened. Accessing stik_cfg->client_ip
>must give the wrong local IP address then. It depends on what it is used 
>for by the client, if it causes trouble or not.

But surely there must be some way to control in which order they will open..?
If so there is no real problem, except the unavoidable one that _all_ old
clients are restricted to the same port.  This is inherent in the old API
being single-port oriented.

Actually I only intended this compatibility feature to ensure that we can make
a release of new STiK ASAP, without waiting for all clients to be rewritten.
The large majority only want a single dial-up port and (more importantly) that
is all we need provide in order for new STiK to replace the old. Using clients
on more than one port has not been possible before, so naturally only newer
client versions will be able to handle that.


>> >The difference is that some people operate their machine without any dial-up 
>> >connection, maybe a dedicated line to some host, or a LAN. The approach 
>> >will fail in those cases.
>> 
>> Why ?  Communication is still through a port, and for that to be legal that
>> port must have been opened somehow.  At that time the IP address of it should
>> be noted in the CONFIG structure.
>
>Yes, but a port (network interface, I use the latter term here, because 
>it is not to be confused with high level protocol ports) that is opened 
>later will overwrite this IP address by it's own one.

Precisely what I intended.  If a dial-up connection is made it will always
ensure that the new dynamic IP is recognized, and if no dial-up is wanted
the drivers should be so configured that the port needing old clients is
the one to be opened last.  With dedicated lines the opening sequence should
only occur once per boot, so no confusion should be possible.


>Maybe a misunderstanding, and you really meant high level protocol ports, 
>and wanted to fill in client_ip by the corresponding open call ? 
----- snip -----> re: changing IP at TCP_open or similar calls

No, that was definitely never my intention.  Traffic may of course be passing
on several ports at once, and that should never affect the single IP-adress
used as local-IP by the oldfashioned clients. This should only change when a
device port is opened for network use.


>> It may be a good idea also to overwrite this IP value with an illegality flag
>> whenever the port it stands for is closed (mainly for dial-up disconnection),
>> to ensure that clients intended for dial-up use recognize disconnection.
>> This should never happen on dedicated lines, so it should cause no problems
>> with them.
>
>Obviously you did not mean TCP ports.

That is correct.


>What you describe here is not significant if the client is properly 
>written. The client wouldn't access client_ip anyway without having a TCP 
>connection open, if client_ip is only used the way Steve recommended. If 
>there is no physical connection, the TCP_open will return E_UNREACHABLE, 
>and no connection will be opened, so the client must not access client_ip 
>(doesn't make sense to do so). If the physical connection has been shut 
>down during TCP communication then a TCP_send or any of the CN* calls 
>will return an appropriate error.

Are you sure...?
Some  clients are still very inconsistent in recognizing disconnection,
and this is especially the case if STiK was connected when they started.
This may of course be due to insufficient testing of return values.
Even so, I suspect that one of the internal tests in STiK makes a mistake
so that some flag set on connecting is not cleared again on disconnecting.

If I test before having made any connection all clients agree, but after
having disconnected a connection some still react as if online.


>No client will have the means anyway to determine if a physical 
>connection is broken or not. It's not it's business anyway.

True, and therefore it is the definite responsibility of STiK to provide
error codes for any API calls inappropriately used in disconnected state,
and the clients should always test return values for these codes.
If this is consistently done then you are of course right, and the IP value
can safely be ignored in disconnected state, since it never can be used.


>Note that I never wrote that I'm against that proposal. It's probably the 
>best that can be done about this problem. Just pointing out that it's far 
>from being foolproof.

Good.  I naturally agree with all of this too.  There is no foolproof way
to make clients perform perfectly without using the new API, since that
is the only way to use them on more than one port at a time.  Those who
make small Intranets would probably like to be able to run CAB on one port
while making an MG-FTP transfer on another port etc, but such uses will
have to wait until the clients involved have been rewritten.

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