[openssl-users] Response from server is lost on close
ant.rao at gmail.com
Thu Dec 10 01:49:38 UTC 2015
Thanks for your reply, and appreciate your answer which clear many of my
Currently i'm stuck with this problem, can't find a way out,let me give
more context of my problem.
I use non-blocking openssl to interact with Apple's APNS server to send
notifications to Iphone devices.
According to protocol of APNS server, most of the time, there is no
response from server; nevertheless ,if bad things happens, server will send
a reply and close the underlying connection.The reply, which is very short,
should be fit in one TCP segment.This can be confirmed by result of
tcpdump, which i post at the beginning in this thread.
So I always write to server until write operation fails, then i try to read
the reply. There is one observation when doing test, if i throttle write
speed to some extent, response can be successfully fetched. However, if i
speed up write speed, response will be lost most likely.
Hopely you can look at this when you have time ,Thanks.
On Wed, Dec 9, 2015 at 10:19 PM, Michael Wojcik <
Michael.Wojcik at microfocus.com> wrote:
> (Sorry for the delay in replying - I was tied up with other things.)
> Yes, you're correct. I was misremembering, and should have checked
> references first.
> The BSD implementation that Gary Wright and Rich Stevens describe in *TCP/IP
> Illustrated* v. 2 drops queued outbound data (on both sides) and queued
> out-of-order segments waiting for reassembly on the receiving side when an
> RST is received. But it doesn't appear to drop queued in-order, ACK'd data.
> And I think that's the correct behavior. If the side that receives the RST
> has ACK'd some data, then it should hang onto that data for the application
> to receive it. It should only report the error (ECONNRESET) when the
> application has successfully read the queued data.
> So I suspect what you're seeing is OpenSSL behavior. It's likely reading
> ahead, seeing the ECONNRESET, and discarding the received data. But I
> haven't had a chance to look at the OpenSSL code in question.
> In some cases OpenSSL will have to read ahead. It needs to receive the
> complete SSL/TLS/DTLS record before processing it, for example; and if that
> record is broken up into multiple TCP segments (because the path MTU is
> smaller than the record size) then it could have a partial record when it
> receives the RST. I can't tell if that situation is present in your case
> (without manually decoding the tcpdump trace, which I don't have time to do
> at the moment).
> Michael Wojcik
> Technology Specialist, Micro Focus
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users