I have implemented a TCP/IP stack on a PIC24 - I have an issue transferring larger files
Some preliminary information:
- Browser: Firefox 104.0 (64-bit)
- Server: Custom code. My server allows up to 18 sockets, 6 of which can be HTTP connections.
I have one last issue with my server implementation that I just cannot figure out. If the request is for a somewhat small file, usually the transfer happens without issue. When requesting larger files, the file transfer stalls.
My test case that works: Open a tab and enter http://SA-8.lan/favicon.ico. Hold shift and click on refresh. All works ok. favicon.ico is 489 bytes.
My test case that fails: Open a tab and enter http://sa-8.lan/js/math.min.js. Hold shift and click on refresh. Fails. math.min.js is 451.4 kB
This issue is that when the page is refreshed on the large file transfer, Firefox initiates a second HTTP request during the transfer of math.min.js. This should not present a problem as my server opens another socket (because the port number is different) and handles the 2nd request. What's odd is that when the next packet of the first socket is sent, the browser does not ACK it.
The sequence and ack numbers all look fine. Wireshark recognizes it as a TCP segment of a reassembled PDU. For some reason that I cannot understand, the browser does not ACK and, after a long delay, sends a TCP Keep-Alive with the Sequence # minus 1.
Why does the browser not respond to my packet segment?
Apparently I cannot attach the wireshark pcap until I have >60 something, so here is a link to a shared file: https://ln5.sync.com/dl/ac4466430/ykdcndnf-2tkf7zuk-fk2nuujs-q5ytenpk. Also, here are the pertinent packet bytes in text form - Transaction No. 86 does not get a reply. Why?
No. Time Source Destination Protocol Length Info
1 0.000000000 10.0.0.188 10.0.0.225 TCP 74 39890 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1312662211 TSecr=0 WS=128
2 0.001636251 10.0.0.225 10.0.0.188 TCP 66 80 → 39890 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460 SACK_PERM=1 WS=128
3 0.001673090 10.0.0.188 10.0.0.225 TCP 54 39890 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0
4 0.001745945 10.0.0.188 10.0.0.225 HTTP 454 GET /js/angular.min.js HTTP/1.1
5 0.003977207 10.0.0.225 10.0.0.188 TCP 60 80 → 39890 [ACK] Seq=1 Ack=401 Win=186880 Len=0
6 0.024330297 10.0.0.225 10.0.0.188 TCP 1514 80 → 39890 [ACK] Seq=1 Ack=401 Win=186880 Len=1460 [TCP segment of a reassembled PDU]
7 0.024361342 10.0.0.188 10.0.0.225 TCP 54 39890 → 80 [ACK] Seq=401 Ack=1461 Win=64128 Len=0
8 0.038601693 10.0.0.225 10.0.0.188 ...
For real you can put a capture file on a publicly accessible file sharing site and post a link here.
Excellent suggestion. Done. I guess I was too tired to think straight when I posted my question (after 1AM local time).
What's going on here:
81 1.306119233 10.0.0.225 10.0.0.188 HTTP 60 HTTP/1.1 503 Service UnavailableMy mistake - I posted a version of the capture where I was experimenting with limiting the number of allowed HTTP sockets to 1. I recaptured with the number of allowed HTTP sockets back to 6. Sorry about the confusion, but the outcome is still the same - the browser does not ACK the data packet.