To: stik-beta-testers@list.zetnet.co.uk
From: dlanor@oden.se (Ronald Andersson)
Organization: Atari
Subject: STinG TCP 1.18 beta results
X-Mailer: NEWSie Version 0.94 (Atari)

Hi Olivier,

Thanks for the feedback.  It is needed for future improvements,
so I am a bit surprised that most other testers never report...


>Good job, I have just notice that with handle = TCP_open(INADDR_LOOPBACK, 
>80, 0, 500 ); + TCP_close() without server, the CIB stay, and handle is 
>positive.

The handle should be positive in this case.  TCP_open only detects a few
error cases directly, such as an unroutable destination IP for example.
The loopback addresses are always routable, since they use an internal
routing independent of ROUTE.TAB.  Apart from that STing treats their
traffic just as for any other address, so the datagrams still have to
pass both sending and receiving routines to reach the 'other end'.

The fact that the 'other end' of the connection then happens to reside
on the same machine does not matter in the least. It is still traffic.


>So I think that is TCP_open problem because it never return E_REFUSE,

The correct error message when no listening port is waiting on the
destination machine is indeed E_REFUSE, but since that is a result
that can only be determined at the destination, some datagrams have
to pass back and forth (even for loopback) before the source can
be informed of the error.  That should happen through an ICMP error
message, which will alter the status of the TCP_connection.

This means that TCP_open is not responsible for testing this, since
it is defined to return to caller without any delay.  Thus E_REFUSE
is not one of the possible return values of TCP_open.

E_REFUSE can only be detected by functions called after TCP_open,
and that is an inevitable consequence of how TCP_open is defined.


>the memory is released only if TCP_wait_state(TESTABLISH) is called and
>return something != E_TIMEOUT ( any contact with the remote stack ).

In fact other functions too should be able to do it, but there is an
error involved here.  It is in fact the TCP reception routines that
are responsible for sending ICMP error messages to the source party
whenever they find an error situation for incoming TCP packets, such
as a call to a listening port that does not exist at the time.

Unfortunately the port number test is currently handled with a group
of other tests, so that it only results in a TCP RESET packet, rather
than an ICMP error message.  This will need to be corrected in another
beta release.


>Resume:
>------
>
>Remnant in case of TCP_open()+TCP_close() if TCP_wait_state() is E_TIMEOUT.
>
>Is your opignion?

I agree on the symptoms, but not on your conclusions.  It is the lack of a
proper ICMP error message that leads to timeout rather than E_REFUSE for
most TCP functions, and there is a bug involved with TCP_wait_state that
would make it able to malfunction even if the ICMP message arrived. I
have just noticed that it only checks for network errors before starting
the timeout loop, but it is most likely that an error message would come
in during that loop's execution so that loop code must also be fixed.

Naturally I will also check this type of behaviour for other loops as
well, while I am about making these changes.

You may expect a new beta release later today.


Btw:
Your test example used port number 80 (standard HTTP port), and this has
reminded me of an odd thing I've seen in using TUR_GEM.  It appears as
if that program itself opens TCP port 80 with seemingly random timing
(sometimes it is shown, but sometimes not), and in a nonfunctional
state (judging from TUR_GEM icons).  Is this correct ?

If so, could I please have a version of TUR_GEM that does not itself open
any ports at all.  For some tests this is very important.

