Content originally posted in LPCWare by MikeSimmonds on Sat Jan 31 20:33:03 MST 2015
This looks like it may be a problem with the implementation of the TCP stack -- you didn't say if it was roll your own,
(LPCOpen) LWIP or what.
When TCP has received enough to momentarily fill it's buffers (i.e doesn't want any more for a bit) a field in the TCP
packet header for the ACK (or ACKS) called 'window' is decreased to indicate how much more data (i.e input packets)
can be handled. This is even allowd to reduce to zero. When the application has emptied (i.e retrieved) enough data to
free up some the TCP stack's buffer space, this window field will be increased. [This is a simplification].
Also, if packets arrive that cannot be handled, the ACK number doesn't acknowledge anything out side the so called
receive window. But then the other end will re-send them assuming that they were lost.
This suggests that the TCP stack on the 1778 is not fully complient, or that Flash Magic is ignoring the window
advertisement (or at least Window's error response from a 'send' call).
See "RFC 793" (Google, freely available, for the 'Standard' description of TCP) or (again Google) any TCP info
website. This is obviously somewhat technical, and may be more than you wanted to know.
Your Wireshark logs will show if this (guess) is true or not when you inspect the packet headers (from the 1778).
I hope that this will point you in the right direction.
Regards, Mike
