[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Socket Reset
Scott,
Based on what my program did, I did get the -1 error. I'm planning on
changing the code to retry "x" number of times before giving up on
processing, but I haven't added that yet.
This error is very sporadic; I might see it once a month out of thousands of
transmissions so it would be very hard to try to catch it again. Like you
said, it's probably a piece of hardware in the communication line that
hiccups occasionally, so I really can't recreate it to test.
Thanks,
Kevin
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, June 4, 2015 8:52 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Socket Reset
Kevin,
Ah, sorry, I missed that you had sent the debug log. Should I assume
that this means that you are indeed not getting the -1 error?
I can see one possible reason why that would be -- after the handshake
fails, it looks like HTTPAPI is still trying to dump a lot of SSL
diagnostic information to the debug log before ending. It should still
work as expected, but it's possible that some of that diagnostic info
failing is screwing things up...
Can you try my test copy and see if that resolves the problem? You can get
it from http://www.scottklement.com/httpapi/beta
Try that out and see if you can trap the #30 error with that copy. If so,
let me know so I can incorporate the fix into future releases.
Thanks!
On 6/3/2015 4:09 PM, Kevin Wengert wrote:
> Hi Scott,
>
> Thanks for the recommendation. I'll add a loop for any error and just
> retry; that makes a lot of sense.
>
> I included the entire debug log with my last response. I'll attach it
> again for your convenience.
>
> Thanks,
>
> Kevin
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
> Klement
> Sent: Wednesday, June 3, 2015 1:57 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: 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/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj
>> 6
>> v5dlPl
>> N7fRYjzd7ldzW4X9Hrn1pctGFW4mgbKq1k1H6H0?si=5663939049816064&pi=6550b2
>> c
>> d-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
> ----------------------------------------------------------------------
> -
>
>
> ----------------------------------------------------------------------
> - 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
-----------------------------------------------------------------------