Re: RC = -1, yet URL Successfully Contacted

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Wayne,

I don't exactly understand what's going on, and I haven't encountered 
this problem personally.  Let me tell you what I do know:

a) The error you reported is CPE3426 -- it's not generated by HTTPAPI, 
it's generated by the TCP/IP network stack in the operating system. 
(HTTPAPI is only telling you what the operating system told it.)

b) CPE3426 is better known in the Internet community as ECONNRESET, and 
it means that a TCP packet was received with the RST bit set.  In 
theory, the operating system should ONLY report ECONNRESET to 
applications if this is true.

c) The RST bit in a TCP packet means that an error occurred in the TCP 
protocol.  Note -- this is NOT the same as an error in the HTTP 
protocol, which HTTPAPI implements.  HTTPAPI does not implement the TCP 
protocol, that's done by the operating system.  And, at any rate, the 
RST bit wasn't even set on your computer -- it was set by the computer 
that's sending data to you.

d) Is there a way that an application can trigger a RST?  Sure.  You can 
turn linger on, and then set the linger time to zero. If that's what's 
happening in your situation, it would be the server application that has 
done this, since it's the server that's sending the RST packet. Then, 
when the server closes it's socket, data in the buffer is discarded, and 
that'll cause a RST packet to be sent to the receiver saying "connection 
ended, but I can't send you the rest of the data..."

Another way is to try sending to the server after the server has called 
shutdown() to stop the receiving ability of it's socket.

Aside from those two things, as far as I know, the only way to get a RST 
(and therefore an ECONNRESET) is due to bugs in the operating system itself.

e) Because of the linger thing I mentioned in the last paragraph, this 
error could occur while receiving a document from a remote host.  It 
would indicate that the host closed the socket.  If you're working in a 
"Connection: close" situation (as Wilbert & I were discussing) then this 
could be a semi-normal indication that the download is complete... which 
is why I thought that fix might help you.

f) Since you say the error is occurring in RespProc() -- then you're 
experiencing an error. There should never be a disconnect during the 
RespProc() procedure because you're supposed to receive data from the 
host *after* the response is received.

So it doesn't make sense for the server to be closing it's socket at 
this point -- so it seems unlikely that the ECONNRESET is due to an 
application error.  But that's just a guess.

g) Another guess:  if it's not an application error, it's a protocol 
error.  You're obviously receiving packets -- so it's unlikely to be a 
hardware problem.  Therefore, it's a bug somewhere in the operating 
system, either on the HTTP server or in i5/OS.

Here's an interesting discussion about ECONNRESET
http://www.webservertalk.com/message1967474.html

If you want to help solve this problem:

a) Send me a debug file.  (this is generated by putting http_debug(*ON) 
at the top of your C-specs/free in your RPG program, and it'll write a 
file to your IFS at /tmp/httpapi_debug.txt containing the debug info.

b) Tell me how to reproduce the error on my system.  If I can reproduce 
it, it's much more likely to be solved.

c) Look for PTFs related to ECONNRESET, ERRNO 3426 or CPE3426.  I know 
that IBM has fixed bugs in the TCP stack in the past that cause these 
errors.



Wayne Hardey wrote:
>         Thanks for taking a shot at this one.  Unfortunately, either 1) I
>    have not communicated my problem sufficiently to you, or 2) your
>    proposed solution didn't fix it.  I did incorporate the code changes
>    per your email, but my results are still the same.  I have been able
>    to debug the entire process, and have found the place where I think
>    the "smoking gun" is laying.  The RespProc procedure (highlighted in
>    RED below) causes a return code of -1.  I must admit that this whole
>    process is more than a little beyond my comprehension level, and I'm
>    having a tough time figuring out just what's wrong, or why.
> 
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------