Hello WIZNet Community:
We are using the WIZ550io SPI <-> Ethernet module interfacing with the NetBurner™ MOD5541X module. Pretty much successfully implemented and working nicely - mostly…
The WIZ550io is set up as a server to interface with a laptop as a diagostic tool for our system. A main function is to download, from the NetNurner to the laptop up to megabytes of data, in 2000 byte blocks. Wireshark shows the following interchange for transaction of one block:
WIZ550io (Server): Laptop (Client)
<------- Request for next packet [PSH, ACK] Len = 2
- [ACK] --------> Len = 0
- [TCP Window Update] --------> Len = 0
- 1st data segment [PSH, ACK] ------> Len = 1460
- 2nd data segment [PSH, ACK] ------> Len = 546
<-------- [ACK] Len = 0
<------- Request for next packet [PSH, ACK] Len = 2 ....
So the problem is the [TCP Window Update], which supposedly serves to negotiate the “window size” field. Not at all sure why this is even there.
So fIrst, when we do an analysis (via Wireshark) of the SAME FUNCTION, but via one of the NetBurner Ethernet ports, we do NOT see any [TCP Window Update] msgs. Interesting. Normally, however, this additional msg from WIZ550io does NOT seem to impeded the data downloads.
HOWEVER, occasionally, what we see is a ONE SECOND time interval between the [ACK] (msg 3) ) from the WIZ550io and the transmission of the [TCP Window Update] (msg 4) )!! and this occurs at EVERY sequence, as shown above. So for 10 MB of data, at 2K/second… do the math, and we’re looking at more than an hour!
So this is a problem.
IS there a quick & easy way to tell WIZ550io to NOT try to do any window size negotiation - i.e., just eliminate the sending [TCP Window Update] Messages entirely? That would be the simplest solution.
Thanks for any help or insight.
Ron (in Pittsburgh Strong)