Thank you for your support.
We was already considering UDP as a base for communication on other devices in development,
maybe we will "switch back" to UDP also on this device!
Regarding the handshake issue, I think the phrase I wrote yesterday
lwIP device replies to a retransmission with ack = 27631 despite it never receives ack = 27857. Perhaps I miss something.
leads to misinterpretation. Now I'll try to explain better my doubts... if can you help me understanding ;) Following the communication, we have: - On packet 10431, the PC sends a request to the lwip-device, seq 7207 and ack 27631. - Then a collision happens, and the packet that should have IP identification 2105, seq 27631 and ack (7207 + 58) = 7265, gets lost; the expected size of the data should be 226 bytes, equal to all previous transactions. - After about 200ms, in packet 10459, the PC retransmits previous request, seq 7207 and ack 27631, as on packet 10431; this retransmission is fired by the PC's network stack (TCP layer?). - Almost immediately the device replies (p. 10464) with an ack, that WireShark attributes to packet 10431: the ack number the device tells to be expected is now (7207 + 58) = 7265 and it should be ok. Seq now is (27631 + 226) = 27857, so the device continues to follow his byte count; this leads me to my first question: by receiving packet 10459, shouldn't the device be already aware that a "desynchronization" happened? if yes, must we consider that this is the way to "inform" the PC that some error happened and that now it (the PC) must acknowledge that subsequent data wil be sent from 27857 (so in this way the device can know how many data retransmit at the retransmission timeout)? - Then, the PC makes another request (p. 10540) with seq = 7265 and ack set to 27631, that i think is the PC expected to see in the reply to packet 10431 (or 10459?). I think this request is fired by the high-level application on the PC, that was configured to retry after 500ms; so I consider that the data on this request are "brand-new" and should cause the high-level application on the device to be informed, causing a reply. - The device now sends the acknowledge (p.10541) and replies (p. 10542) with the usual 226 bytes of data: seq continues to follow the device's byte count and now is (27631 + 226) = 27857; ack is (7265 + 58) = 7323. I expected that the data in the packet was "brand-new" (in reply to request in packet 10540) and not some sort of low-level retransmission; but (and I forgot to tell you this previously) the high-level application on the PC did't receive (at least in this moment?) this reply. Did it happen because the PC network stack was "locked" waiting the data in the lost reply? If it is the case, should I expect that the data in this packet will be passed to the PC application after receiving (and passing to the application) the lost data? - Now the PC sends a "duplicate ACK" (p. 10543) wit seq = 27631. If I'm not wrong, this is caused by the PC's TCP layer that "sees" the over-than-expected device's data pointer and requests missing data (from 27631). But we can consider this is also an aknowledgment for the data sent by device on packet 10542? - On packets 10645, 10646 and 10647 the last two points repeat. - When finally the device repeats the missing packet (p. 10685), the PC sends an acknowledgment (packet 10686) with ack = (28083 + 226) = 28309. Now the data sent by the device in packet 10646 is surely acknowledged, right? - But now, why the device repeats (with packet 10687) the data from byte 27857? Because it has not received an acknowledgment for that packet (so it was not implicit in acknowledgment sent with packet 10543)? And if yes, why the PC's TCP layer as not sent the acknowledgment to packet 10542? Thank you very much Enrico
On 06/05/2011 10.08, Kieran Mansley wrote:
On Thu, 2011-05-05 at 18:38 +0200, Cristiano Toninato - Research & Development - CET wrote:Ok, but our application should work in a LAN, with an RS485 backup (if the Ethernet does not work). Normally all works within few tenths of second, and we cannot lose control of the system, after 3 seconds not working on LAN we should switch on RS485.For a specialised control application like this you might want to consider avoiding TCP altogether as it doesn't have the real-time properties that you'll need. You would then have to implement your own transport layer (perhaps on top of UDP), or make do with just UDP if uncorrected packet loss isn't a problem. Kieran _______________________________________________ lwip-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/lwip-users
--
Enrico Murador
R&D
Enrico Murador
R&D
 |
CET
Electronics via E. Fermi, 1 31050 Zenson di Piave (TV) Italia Phone: +39 0421 344100 Fax: +39 0421 464042 Web: http://www.cet-electronics.com/ |