Mail To: Peter Rottengatter <stik-beta-testers@list.zetnet.co.uk>
Subject: Re: New TCP_close()
----------------------------------------------------------------------------

On Sun, 13 Dec 1998, Peter Rottengatter wrote:
>On Sat, 12 Dec 1998, Ronald Andersson wrote:
>
----- snip ----- re: adding special cases for TCP_close timeout value
>> 
----- Case 1:  (timeout > 0) -----

No more needs to be said of this mode, since we agree fully.


----- Case 2:  (timeout == 0) -----
>
>You're probably misunderstanding the purpose of this suggestion of mine.
>I do not intend to encourage to use this mode anymore, the proper use for
>the future should be the mode with the timeout parameter set to negative.
>However, there are lots of clients that just use zero.

Ok, I see what you mean now, and so agree fully on this mode too, though I
still have a few comments (added below).


----- snip ----- re: need of default delay for 'case 2' TCP_close negotiation

I still think 1000 sec. is a lot.  If there is ever enough congestion to
delay responses by over 16 minutes I'll 'pull the plug' anyway. But I do
not think that it is an important issue for normal circumstances, so I'll
agree to your timing.


>A TCP_close() that is intented to ensure (by it's return value) that data
>has been delivered safely, must be called in the first mode with very
>large timeout parameter. Alternatively (better), TCP_close(...,-1); must
>be called which allows access of the connection to catch error conditions.

Yes, but APPs that use this mode should also use all the other workarounds
currently needed for safe closing by data senders, this means that all the
data should already be ACKed when they call TCP_close.  That should ensure
delivery to the opposite APP even if the TCP_close negotiation fails.

In any case it is the best we *can* do for old clients using this mode.
Any 'fancy' improvements will require changes in the clients as well.


----- snip ----- re: socket combination lockup

>The socket combination lockup is not a problem. Note the connection will
>only then last all the time if the remote does not send it's own FIN (once
>it does, the connection is about to be closed within short time anyway).
>As long as the remote doesn't send the FIN, the port combination is blocked 
>in any case, whatever STinG does.

I don't see that.  If the local APP calls TCP_close, then we dump that
socket combination after the timeout period, with or without any incoming
FIN packet. It is only for the timeout period that the socket combination
will be blocked, and that is why I felt 16+ minutes was too long.

In any case, I don't think it is worth arguing over, since all clients that
are still supported should be updated to make use of third case of TCP_call,
with a 'timeout' of -1.  This should eliminate all the problems, though I
still think some modifications are needed to the method you described.

----- snip ----- re: the rest of the argument about 'case 2' timeouts


----- Case 3:  (timeout == -1) -----
>
>
>I do not have the time right now to comment on this part of your mail.
>Just this note : You shouldn't try to create the impression that large
>parts of the API were blocking.

It is not something I *try* to do in order to make anyone look bad, and
you should know that.  Especially as I have been involved myself in some
of the design choices leading to the present interface...

In fact I think we have done a hell of a good job, in smashing down the
walls of what others said was impossible to achieve and still have STinG
remain compatible with singleTOS.  I just don't think that this work is
finished yet, and that some forms of blocking still need to be solved.


>Nothing except TCP_close() is blocking.
>And since just that is about to be redefined, I think we can unblock it
>without starting an extended unblock-campaign ;-)

Sure.  I have said all along that we should complete a new release ASAP,
before undertaking any new major changes.  Whether that release is to
include an unblocked TCP_close, or merely a bugfixed one, that is up to
you of course.  But after that release we should look at the issue
of 'blocking' again, because that is still a factor limiting STinG.


NB:  There are many different kinds of blocking involved.  The most
common complaint earlier was that other multitasked APPs were blocked.
That has indeed been pretty well eliminated now, but the methods used
to do it may be a problem for interrupt driven API use.
(eg: Supexec, _appl_yield, semaphores, etc)

Thus we have another form of 'blocking' specifically for routines that
are interrupt driven, or are used as part of TOS function enhancers.
(Such as Vassilis discussed earlier.)  My suggestions posted earlier
would simplify the removal of the TOS calls in the API that created
this 'blocking' effect.

The current 'block' issue we have spoken most of, as you know, is the
blocking of the APP that called the API. This remains a serious problem
for TCP_close, TCP_ack_wait, and TCP_wait_state.  In other words, for
all the cases where the calling APP needs assurance that some phase
of the traffic on the connection has been completed.  My suggestions
would definitely solve those problems too, making all of them capable
of returning without delay to the calling APP, so that it can continue
to service windows and menus etc, while awaiting TCP function results.

Finally there remains an effect that is similar to 'blocking' though not
quite the same thing.  Most of our 'unblocking' functions today rely on
the user APPs repeatedly calling some STinG functions to find out if
the data they want has arrived yet or not.  When made frequently, by many
APPs in parallel, the overhead of such calls becomes significant in its
effect on execution speed, since they do 'block' the CPU from using those
time cycles for other things.  My suggestions would reduce the overhead
when an APP is waiting for data to the simple checking of a local variable.


>Besides that, it's a real hassle to invent new CN* function, so I hope we
>can do without.

I have suggested a total of one new CN* function, though some of the
stuff I've discussed does imply internal kernel changes with similar
(or even worse) 'hassle factors'. In fact it could be done with separate
TCP and UDP functions instead, but that seems less natural to me.


>I'll try to dig up on that block-related posting of yours, and read it
>thoroughly. Just can't do now.
