<div dir="ltr"><div><br></div>Thanks Jakob & Michael for your reply. <div>I'm using openssl to interact with apple's APNS server. Sending data as fast as possible, most of the time APNS server don't reply, but in some circumstance, APNS server will rely with a response and then close the connection. So the RST is expected most of the time if APNS don't process all received data.</div><div><br></div><div>At first i doubt this is maybe properties of TCP : tcp discard received data on RST. and i do some test on TCP not openssl.</div><div>1. client</div><div>write data until the connection is broken, sleep for a number of seconds, then try to read. the response can be read.</div><div>2. server</div><div>on accept, don't read the data, sleep for a number of seconds. and write some bytes ,then just exit.</div><div>here is result of tcpdump on closing:</div><div><br></div><div><div>09:50:10.188952 IP xx.90.82.138.irisa > 10.241.95.197.48252: Flags [P.], seq 730306105:730306205, ack 1556413186</div><div>Connection was reset.,nop,TS val 118133437 ecr 511650777], length 100</div><div><br></div><div>09:50:10.188963 IP 10.241.95.197.48252 > xx.90.82.138.irisa: Flags [.], ack 100, win 6, options [nop,nop,TS val</div><div>511653112 ecr 118133437], length 0</div><div><br></div><div>09:50:10.188971 IP xx.90.82.138.irisa > 10.241.95.197.48252: Flags [R.], seq 100, ack 1, win 39, options [nop,no</div><div>p,TS val 118133437 ecr 511650777], length 0</div></div><div><br></div><div>It seems that if data is placed in socket buffer, it can be read. So the received package could be discard in TCP stack?</div><div><br></div><div>Thank you very much.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 3, 2015 at 7:53 AM, 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 bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just to amplify on Jakob's response: the reason that sometimes you see the reply is that sometimes your application manages to get it from the stack before
the stack receives and processes the RST from the peer. In the example you provided, there was a 52ms window in which you could have read that response before the RST told the stack to throw it away.</span></p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If the conversation is aborting for cause - for example because the peer process exited without reading some received data - then this is the correct behavior.
If the peer is causing the RST by mucking around with the SO_LINGER socket option, then the peer application is probably broken. (There are cases where an application might legitimately want to send an RST rather than a FIN, but they're few and far between.)<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 any event, you're at the mercy of TCP's semantics. When the conversation is aborted, rather than terminated normally, unprocessed data goes away. That's
a Good Thing, because the peer has no way of knowing whether you received it.<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">As is usually the case with this sort of issue, the real question is what problem are you actually trying to solve? "How can I make TCP behave differently?"
is not the right question.<span class="HOEnZb"><font color="#888888"><u></u><u></u></font></span></span></p><span class="HOEnZb"><font color="#888888">
<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"">Michael Wojcik</span><span style="font-size:9.0pt;color:#1f497d">
<br>
</span><span style="font-size:9.0pt;font-family:"Courier New"">Technology Specialist</span><span style="font-size:9.0pt;font-family:"Courier New"">, 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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<p align="center" style="text-align:center"><span style="border:none windowtext 1.0pt;padding:0in;background:white"><u></u> <u></u></span></p>
</div>
</font></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></div>