<div dir="ltr">Hi Michael,<div>Thanks for your reply, and appreciate your answer which clear many of my doubts.</div><div><br></div><div>Currently i'm stuck with this problem, can't find a way out,let me give more context of my problem.<br><div>I use non-blocking openssl to interact with Apple's APNS server to send notifications to Iphone devices.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Hopely you can look at this when you have time ,Thanks.</div><div><br></div><div><br></div><div>Thanks.</div><div>Anty.</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 10:19 PM, Michael Wojcik <span dir="ltr"><<a href="mailto:Michael.Wojcik@microfocus.com" target="_blank">Michael.Wojcik@microfocus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(Sorry for the delay in replying - I was tied up with other things.)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Yes, you're correct. I was misremembering, and should have checked references first.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The BSD implementation that Gary Wright and Rich Stevens describe in
<i>TCP/IP Illustrated</i> 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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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).<u></u><u></u></span></p><span class="">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Courier New";color:black">Michael Wojcik</span><span style="font-size:9.0pt;color:#1f497d">
<br>
</span><span style="font-size:9.0pt;font-family:"Courier New";color:black">Technology Specialist</span><span style="font-size:9.0pt;font-family:"Courier New";color:black">, Micro Focus</span><span style="font-size:9.0pt;color:#1f497d">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
</span></div>
</div>
<br>_______________________________________________<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Anty Rao</div>
</div>