RE: CAsyncSocket performing RST on Connect()
- From: kerry <kerry@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 27 Jun 2007 14:06:01 -0700
Hi Chad,
Have you found a resolution to this issue? I am running into the same
problem. I have a windows client that opens a tcp connection and sometimes
the connection underneath sends a RST just like in your trace. The only way I
detect this is by a 3 second pause in my logs between the connect and the
connect callback. I see the same SYN (from the client), SYN (quickly
retransmitted fromt the client), SYN ACK (from the server), RST (from the
client) that your trace shows. Did you find any combination of reordering
your function calls, or socket options that resolved the problem so the TCP
stack doesn't reset the connection underneath your application?
Thanks for your help,
Kerry.
"Chad" wrote:
.
Hello,
I am having a problem with a TCP client written in Visual C++ v6.0 using
MFC's CAsyncSocket. It runs on Windows XP Pro SP2, and has the same problem
in Windows 2000 Pro SP4.
The client performs transactions with the server in the form of: connect,
send, receive, close, connect, send, receive, close, etc. The problem is in
the "connect" phase: about 15% of the SYN segments from my client are
followed by a RST segment from my client, even though a SYN-ACK is received.
This is a Big Deal because the transaction is delayed 3-4 seconds every time
a RST is present. When many many transactions must occur in a row, this
slows down my application to the point of being unusable.
I have been consulting other programmers, who believe I am closing/deleting
the socket after the SYN. I can assure you it is not. I put logging
statements around every close/deletion, and none of them occur until after
the data is successfully received. Additionally, my program is even using
the same local port number after the RST that is was attempting to use before
the RST. So the socket must be the same.
Inside my application, CAsyncSocket::Connect() is called, then nothing
happens in my program for 3 seconds, and then CAsyncSocket::OnConnect() is
called-back when the connection is successfully established. The socket
operates normally after that. So my application sees nothing strange
happening, even though between Connect() and OnConnect(), a RST occurred.
I have appended a log of the TCP traffic from the Wireshark packet sniffer.
Here is my analysis of the log:
Notice that the SYN-ACK occurred 0.001274 seconds after the SYN. This is
different from EVERY SINGLE successful attempt, in that EVERY SINGLE
successful SYN-ACK occurs in no later than 0.0005 seconds. In other words,
successful SYN-ACK's are received in less than half the time of failed
SYN-ACK's.
Another note: If I run my application in "Debug Mode", there are no RST's
present. As we all know, "Debug Mode" can slow your program down because of
the extra logic. In "Debug Mode", ALL SYN-ACK's consistently take
approximately 0.001 seconds (instead of in release mode, where some are 0.001
seconds and others are 0.0005 seconds).
This is leading me to the conclusion that Windows' TCP logic is calculating
the RTT for the connection. When several socket connections happen in a row
with a quick SYN-ACK, windows lowers its RTT calculation and expects all
SYN-ACK's to be that fast. When a SYN-ACK is relatively late, a RST occurrs,
and the process repeats itself. Several fast transactions, one or a few RST
transactions, then several fast transactions.
Does my conclusion sound correct, or am I missing something essential about
how Windows uses RST? If I am correct, then I can fix the problem by
changing Windows' RTT calculation minimum to a higher value. Is this
possible?
Any advice on correcting this issue would be greatly appreciated.
No. Time Source Destination Protocol Info
251 *REF* 89.194.102.223 89.89.200.210 TCP 3240 >
1152 [SYN] Seq=2088016804 Len=0 MSS=1460
252 0.001274 89.89.200.210 89.194.102.223 TCP 1152 >
3240 [SYN, ACK] Seq=212534098 Ack=2088016805 Win=5840 Len=0 MSS=1460
253 0.001307 89.194.102.223 89.89.200.210 TCP 3240 >
1152 [RST] Seq=2088016805 Len=0
254 3.836323 89.194.102.223 89.89.200.210 TCP [TCP
Previous segment lost] 3240 > 1152 [SYN] Seq=2089045841 Len=0 MSS=1460
255 3.837640 89.89.200.210 89.194.102.223 TCP [TCP
Previous segment lost] 1152 > 3240 [SYN, ACK] Seq=216370502 Ack=2089045842
Win=5840 Len=0 MSS=1460
256 3.837664 89.194.102.223 89.89.200.210 TCP 3240 >
1152 [ACK] Seq=2089045842 Ack=216370503 Win=17520 Len=0
257 3.838146 89.194.102.223 89.89.200.210 TCP 3240 >
1152 [PSH, ACK] Seq=2089045842 Ack=216370503 Win=17520 Len=9
258 3.842209 89.89.200.210 89.194.102.223 TCP 1152 >
3240 [ACK] Seq=216370503 Ack=2089045851 Win=5840 Len=0
259 3.927619 89.89.200.210 89.194.102.223 TCP 1152 >
3240 [PSH, ACK] Seq=216370503 Ack=2089045851 Win=5840 Len=22
260 3.927648 89.89.200.210 89.194.102.223 TCP 1152 >
3240 [FIN, ACK] Seq=216370525 Ack=2089045851 Win=5840 Len=0
261 3.927676 89.194.102.223 89.89.200.210 TCP 3240 >
1152 [ACK] Seq=2089045851 Ack=216370526 Win=17498 Len=0
262 3.928923 89.194.102.223 89.89.200.210 TCP 3240 >
1152 [FIN, ACK] Seq=2089045851 Ack=216370526 Win=17498 Len=0
264 3.930113 89.89.200.210 89.194.102.223 TCP 1152 >
3240 [ACK] Seq=216370526 Ack=2089045852 Win=5840 Len=0
- Prev by Date: RE: CAsyncSocket performing RST on Connect()
- Next by Date: Error 10060
- Previous by thread: RE: CAsyncSocket performing RST on Connect()
- Next by thread: Error 10060
- Index(es):
Relevant Pages
|
Loading
