|Subject:||Re: [lwip-users] TCP Retransmission when receiving consecutive packets|
|Date:||Thu, 20 Mar 2014 16:48:38 +0100|
|User-agent:||Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0|
Yes you're probably right, that would be a better solution. What looks like happens next in the wireshark capture is that the interrupt triggered by the retransmission signals your code to read and ack the queued old packet. Then there's an ACK in packet 26 triggering another interrupt that signals your application to read the queued retransmission packet, hence the dup ack in packet 27. And so on, your application is constantly one packet behind the interrupt.
One comment though: I don't know which MCU you're on but I wouldn't assume one interrupt equals one packet. I recently fixed a bug in my application that had a similar setup (interrupt signals with counting semaphore to receive thread, which processed a number of packets equal to the counting semaphore) which didn't cover the case where a second packet is received before the ethernet interrupt has serviced the first packet. My interrupt would only hit once so the second packet was left until the next interrupt.
My solution was to simply try to fetch packets from DMA until it was empty each time my receive thread was woken.
On 2014-03-20 16:21, Julien Jemine wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|