#62 Why do TCPIPRead*TCP calls return tcperrConClosing with data?

[Andrew Roughan]

Report from Kim Howe:

When you complete a read, Marinetti 3.x generates a tcperrConClosing (tcperr #10) when reading that has to be trapped and ignored. Arachnid, for example, doesn’t do this and so doesn’t work at all under Marinetti 3.x
I've had to trap and ignore that error with ftpNDA.
I found an instance of checking for it on TCPIPReadLineTCP [within my source code]. tcpErr reports connection closing even if the call worked normally [i.e. it actually read the line successfully]. I just trap and log that error, since it really is not an error at all.
I can’t think of another call in Marinetti that returns an error when it worked as expected.

tcpErr = TCPIPReadLineTCP(
    FTPipid,
    "\p\r\n",
    0x0002,
    0L,
    149,
    &ReadBuf);
if(tcpErr) {
  if(tcpErr == 10) {
    sprintf(errorMess, "Connection Closed");
    DoMessage(errorMess);
  }
  else {
    sprintf(errorMess, "Read Error %d.", tcpErr);
    DoMessage(errorMess);
  }
    DoStop();
    DoProgress(0);
    DoDisconnect();
    return;
} /* end of if(tcpErr) */

[Andrew Roughan]

Comment from Kelvin Sherlock:

There could still be received data waiting to be read even if the connection is closing or closed. The only time you need to worry about a tcp status is when you read 0 bytes.
The tcp status is unrelated to whether you actually read any data or not.
I've found it best to ignore any tcp status error unless 0 bytes were read.
Earlier versions may have had different read errors when the connection started closing (like losing buffered data)
http://blog.ksherlock.com/2012/04/08/tcpipreadtcp_return_values/

[Andrew Roughan]

TCPIPReadLineTCP (and all other calls) returns a tool error code. Then you can look at the TCP state machine status separately.
The TCP state machine can indicate that the connection is closing, but that does not mean there was an error with the call.
The TCP RFC 793 contains " Return "error: connection closing" " - it is just part of the spec.
I'm sure its possible for TCPReadLine to have data waiting and see Connection Closing - that's what Kim is ignoring in his FTP program (not the source above)
I expect that TCPIPWriteTCP & TCPIPReadTCP would also be able to see this.
Kim So just to wrap up, "read error 10": seeing tcperrConClosing is a forewarning and it can be ignored.

[Andrew Roughan]

Comment from Geoff Body:

I was reading the RFC 793 page 58, receive call, Close-Wait state description. I read that if the data is available for the call, it's ok, if none available then error with connection closing.
Thats my view of reading the RFC, but I will leave it with you.

RECEIVE Call

    CLOSE-WAIT STATE

      Since the remote side has already sent FIN, RECEIVEs must be
      satisfied by text already on hand, but not yet delivered to the
      user.  If no text is awaiting delivery, the RECEIVE will get a
      "error:  connection closing" response.  Otherwise, any remaining
      text can be used to satisfy the RECEIVE.

[Andrew Roughan]

The code in question is I.TCP.S
http://marinetti.cvs.sourceforge.net/viewvc/marinetti/MOSP/Marinetti/Init/I.TCP.S?revision=1.6&view=markup

1167    :DONEOUT LDY #uwTCP_State
1168             LDA [USERPTR],Y
1169             CMP #tcpsCLOSEWAIT
1170             BNE :OUT
1171             JMP CONCLOSING
1172    :OUT     JMP NOERROR

If this is to be changed, the new code would be as simple as:

1167    :DONEOUT JMP NOERROR

because the :ANYLEFT routine will exit via CONCLOSING if there is no data left.

[Andrew Roughan]

After Geoff pointed out the section in the RFC, I agree that it does appear that there is a problem in the code. I think I must have been reading the section immediately under it when I responded to Kim in IRC.

So, my apologies Kim. I'll get this sorted.

Richard, the problem is in the original open sourced 3.0 source code, but was apparently not behaving like this in 2.x according to Kim (evidence: Arachnid worked in 2.x and it does not in 3.0) - Perhaps you changed it between those releases? I have no way of checking this.
There's no need to dig into when/why unless you think you did it for some deliberate reason. There are no comments in the source WRT this.

[Andrew Roughan]

Code fixed under https://sourceforge.net/p/marinetti/bugs/70/