Hi,
mariuszp wrote:
My network stack has been around for some time but recently I discovered a problem. When trying to download a relatively large file (1.4M) from a server via HTTP, it is unacceptably slow. So I ran wireshark to analyse the traffic. Obviously it's a big mess, but what I think I'm seeing is the following:
1. Server sends some data.
2. Server sends more data.
3. Server sends even more data.
4. Glidix ACKs #1
5. Server re-sends #2
6. Server re-sends #3
7. Server sends #4
8. Glidix ACKs #2
9. Server re-sends #3
10. etc etc etc
Can you provide more detail?
This could be interpreted as:
1. Server sends some data.
2. Server sends more data.
3. Server sends even more data.
4. Glidix ACKs #1
5. Server didn't get an ACK for #2 in time and assumes packet was lost, so server re-sends #2
6. Server didn't get an ACK for #3 in time and assumes packet was lost, so server re-sends #3
7. Server sends #4
8. Glidix ACKs #2
9. Server didn't get an ACK for #3 in time and assumes packet was lost, so server re-sends #3
10. etc etc etc
If that's the case, then the server is working correctly and the client has major performance problems (not sending ACKs fast enough).
Alternatively it could be like this:
1. Server sends some data.
2. Server sends more data.
3. Server sends even more data.
4. Glidix ACKs #1
5. Server re-sends #2 even though receiver hasn't had time to receive the first copy
6. Server re-sends #3 even though receiver hasn't had time to receive the first copy
7. Server sends #4
8. Glidix ACKs #2
9. Server re-sends #3 even though receiver hasn't had time to receive the previous copy
10. etc etc etc
In that case there's a problem with the server (bad/misconfigured or missing time-outs and/or inappropriate window size) and the client is working correctly.
Note: I am assuming that this is on a nice "quiet" LAN, and network congestion is not involved.
mariuszp wrote:
The conclusion that I'm getting from this is that the server isn't expecting every single message to be ACKed, and treats the fast ACKs as indication that data has been dropped. I don't see this mentioned anywhere in RFCs or on wikipedia (i might be blind).
As far as I know; the client can coalesce ACKs (e.g. instead of sending "ACK #1", "ACK #2", "ACK #3" it can just send "ACK #3" to tell server it received everything up to #3); but (even though it's a good idea - e.g. improve performance/reduce bandwidth consumption by reducing the number of packets sent by client) this is a purely optional optimisation, and server can not/must not assume that a packet won't be received simply because it wasn't included in the latest ACK from client.
Cheers,
Brendan