Hi Michael, Thanks for your reply, and appreciate your answer which clear many of my doubts. 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. Thanks. Anty. 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 > > -- Anty Rao -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151210/faa2aaf7/attachment-0001.html>
