[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTP API AS/400 Question

Hi Harold,

In order to send a message to the mailing list, please address it to ftpapi@xxxxxxxxxxxxxxxxxxxxxxx You sent your message to ftpapi-owner, which goes to the person who owns and operates the list (that's me), instead of going to the list itself. (But I forwarded it for you.)

Our software developer, Profound Logic Systems, has used your HTTP (SSL) API to connect to a provider of ours. We submit several hundred requests a day to our provider. We do a post and wait for a response. The provider keeps the socket open for a max of 15 seconds after receiving our post (which contains a request for report) and sending us the requested report.

Are you attempting to use the persistent functions (http_persist_post) or you are using the regular functions (http_url_post)? Unless you're using the persistent functions, the 15 second timeout shouldn't have any bearing on you.

We have a 45 second timeout on the request. We receive the following error back:
  Error Number 6530 occurred on 2006-11-27 at 16.08.26.      Message:
    RPT: HTTPS connection error for transaction number 50686-1: Error
    Number: 44, CommSSL_read:  read:(GSKit) I/O: A connection with a remote
    socket was reset by…

The error number 6530 is not an HTTPAPI error code, and HTTPAPI has no notion of a transaction number.

The rest of the message, however, does look like data from HTTPAPI. It tells me the following:

a) HTTPAPI was caling the CommSSL_read() subprocedure. CommSSL is the SSL communications network driver that comes with HTTPAPI. CommSSL_read() is
the subprocedure that reads data from an SSL communication channel.

b) CommSSL_read() was reading data from the SSL socket. It does this by calling the gsk_secure_soc_read() API provided by IBM as part of i5/OS.
More info on that API can be found here:

c) The API returned an I/O error (GSK_ERROR_IO). When the GSKit returns an I/O error, you're supposed to check the 'errno' global variable to see which error has occurred. HTTPAPI has done that, and found errno 3426 (also known as CPE3426, or ECONNRESET) was the value of the error number.

d) If you look up the message for CPE3426 (type DSPMSG CPE3426 at the command line of a 5250 screen) you'll see that it means "A connection with a remote socket was reset by that socket".

From there, all I can do is guess. I didn't write the gsk_secure_soc_read() API, it's part of the operating system! I can't tell you for sure why it received this error. All I can tell you is which error it has reported, and what the documentation says about that error.

The ECONNRESET error is supposed to occur only when the program on the other side of the connection (in this case, an HTTP server) has closed the TCP session. In other words, it disconnected you. Much like when you're talking on the telephone, and you suddently hear a click and a dial tone -- you say to yourself "hey! they hung up on me!"

I also have traces from ETHERREAL packet sniffer which does not indicate that any errors were detected on receipt of on our side. Some retransmit requests were seen for the report provider. It appears that we are possibly dropping received data or not detecting dropped packets.

You shouldn't be looking for errors in Ethereal, you should be looking for the RST flag (RST="Reset"). Presumably, the HTTP server is setting the RST flag in the control bits of the TCP header.

At any rate, all HTTPAPI does is relay the error to you. If the API reports ECONNRESET, then HTTPAPI relays it to you. If the ECONNRESET is not supposed to be happening, it's a bug in the gsk_secure_soc_read() API (or a lower-level API below it) and that's part of the operating system, not HTTPAPI.

But, if you know (or learn of) a way that I can work around the problem, I'd be happy to give it a try.
This is the FTPAPI mailing list.  To unsubscribe, please go to: