[openssl-users] Response from server is lost on close

[Anty Rao]

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>