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

Re: Socket Reset

Kevin,
In the world of communications, you have to expect errors to occur sometimes. This error (which is more properly known as "Connection Reset", not "Socket Reset" -- the phrase "Socket Reset" doesn't make a lot of sense) is a normal error that can occur sometimes, especially if there is some flaky hardware somewhere out there.
If it's only happening once in a while, then I would suspect that the network is getting overwhelmed with requests or something like that.
If it happens every single time, then it may be a software error and would require more/deeper look.
As for your code, no rc will never be 30. The return code from HTTPAPI is either a positive number when the server reports an error (like 403 forbidden, 404 not found, 500 internal server error, etc) or for errors like this, it returns -1. You can call http_error() to get the specific error that occurred, so the code would be like this: 

rc = http_url_post(%Trim(URL) : pXmlBuffer + 2 : DataSize : wResponse);

if rc<>1;
    http_error(err);
    if err = HTTP_SSSNFD;
      // error occurred during SSL handshake, handle it here
    endif;
endif;
Having said that, I'm not if I'd be this specific (only handling this one particular error) instead of retrying on all errors. Sure, it's happening during the SSL handshake now, but a communication error could occur anywhere. Why not just handle all -1 type errors, retrying say 5 times if needed?
Mike is implying that this error is not "bubbling up" If that's the case, it'd be a bug in HTTPAPI, and that will cause a bunch of spurious errors after this occurs. I would need the entire debug log to help with that (you can just delete the sensitive stuff, and send me everything else.)
But, I'm not sure if that's true (that it's not bubbling up) or whether the issue is just that you didn't know that you needed to check http_error()? 

-SK


On 6/3/2015 1:45 PM, Mike Krebs wrote:

Looks like some debug is needed in the bowels of the service program as I would think the error 30 should have bubbled up and stopped any further activity. Maybe Scott could hop in here and offer some explanation.

But you did get more activity...The debug is showing a 0 length message sent at least twice. So, from that standpoint, the web service acted accordingly. Part of the question becomes why did the program send 0 length messages twice (the first one ending in a timeout). Is this a multiple request program and steps 2 and 3 ran even though 1 didn't?

Is step 2/3 using something that step 1 is supposed to build? Maybe  a if xmldata<> '' is needed to prevent 2 and 3 from running?



-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Kevin Wengert
Sent: Tuesday, June 2, 2015 5:29 PM
To: 'HTTPAPI and FTPAPI Projects'
Subject: RE: Socket Reset

Hi Mike,

It didn't try to parse the result, but it did receive the response.  My program got an error, so it did nothing with the information it received.

Here is my code trying to get the delivery receipt:

rc = http_url_post(%Trim(URL)
                   : pXmlBuffer + 2
                   : DataSize
                   : wResponse);
Right now, I'm only processing if rc = 1. Would rc = 30 when I get the handshake error? If so, I could create a loop to retry until rc <> 30? I think that would fix half my issue. 

I've also attached the entire debug log, except the portions that are sensitive.


Thanks,

Kevin

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Krebs
Sent: Tuesday, June 2, 2015 2:34 PM
To: HTTPAPI and FTPAPI Projects
Subject: RE: Socket Reset

The HTTPAPI procedure didn't return an error after getting the 30 error code?

It doesn't make sense that it just continued on and tried to parse the result. In fact, I am surprised it went on to receive any data.

The error says it happened during the handshake - the sending server should not have seen the request unless they count the initial contact as a request. It is isn't a very secure connection if the request is sent before the handshake is completed.  Seems kind of weird.

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Kevin Wengert
Sent: Tuesday, June 2, 2015 12:24 PM
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: Socket Reset

Good Morning,


I've got a problem that I haven't seen before that is causing me fits.  I'm sending a vendor information about deliveries via HTTP.  Using the same port, I can request copies of the delivery receipts that I then email to customers.  It's important to note that on the same port, if I send an empty request, if their webservice has an xml document describing an order delivery, called an orderSummaryEvent, it will send that document as a response.


Now, the problem.  For each orderSummaryEvent, a unique id is included that I use to get the copy of the delivery receipt.  My customer reported that one of these delivery receipts was missing, and I checked the debug log, which contained this error:


(GSKit) I/O: A connection with a remote socket was reset by that socket.


ssl_error(406): (GSKit) I/O: A connection with a remote socket was reset by
that socket.

SetError() #30: SSL Handshake: (GSKit) I/O: A connection with a remote socket was reset by that


At that point, it looks like my xml that requested the delivery receipt was compromised.  Normally, I can see the request in the debug log, but now it doesn't show with the "senddoc(): entered" line in the debug line.  Instead, there is no data there, so the web service thinks I'm looking for an orderSummaryEvent, and happily sends me one.  This procedure has no idea what to do with it and it gets lost.


I'd like to trap the remote socket reset error and retry the request again.
Any ideas how to go about doing that?


Thanks,


Kevin Wengert
<http://t.signauxsix.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v5dlPl 
N7fRYjzd7ldzW4X9Hrn1pctGFW4mgbKq1k1H6H0?si=5663939049816064&pi=6550b2cd-43c3
-4845-9c81-42099cac9078>
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------



-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------