Why does the client not hear the #64674? Is there corruption happening? Or overloaded network between (loss)? Or maybe the ACK (#64671) confused it so it ignores the My second question is why the two ends are no hearing each other. Myu only *guess* is that the server is very busy and sends an ACK to say "yeh I'm here but". Double-checking RFC 793 shows the only action on listen+SYN is SYN+ACK. After the next SYN repeat from the client it again responds with the expected SYN+ACK. The server appears not to respond to the first two and then sends an ACK (#64671) to the next and then 2.9sec later sends the expected SYN+ACK. So the client is not hearing a response from the server and is retrying at Lets just look at the client's SYNs first, with the time periods (deltas): #64661 d=2seconds #64665 d=4s #64668 d=8s #64679. There's no reasonįor that dup, and it is very unlikely that the client TCP/IP sent it, so it was presumably created by some misbehaving hardware somewhere. All quick, server SYN+ACKs in <1ms and client is ~120ms distant. So, looking at the successful case first. It is a different trace than above, but the with same results. Below is a trace with packet numbers and times.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |