Hi guys,
I have observed the following :
1.I do send() on a UDP socket, which then post the reference to data into the
socket layer.
The application thread then blocks on the semaphore op_completed.
2.The TCPIP thread then checks the mailbox and starts preparing the packet and
queue the reference in
the Ethernet buffer descriptor ring for transmission.Since the ring buffer
descriptor is rather full the packet
cannot be transmitted at that exact moment by the MAC.
3. The TCPIP thread returns to the point where the semaphore is triggered. It
then blocks and there
is a task change and the application thread is now running.
4. The application thread now rewrites the same data which was not yet sent.
Hence the previous data packet are corrupted.
This only happens when we have high frequency sending and only with UDP since
TCP copies all the data into the TCPIP stack.
I dont know if this qualifies as a bug, I just wanted to point it out to you
guys that this could happen. The workaround can easily
be done on the application layer of course.
My implementation is lwip1.3.0 on PowerPC processor
M Ikhwan Ismail
_________________________________________________________________
See how Windows Mobile brings your life together—at home, work, or on the go.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
