lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] lwIP UDP and TFTP


From: Leon Woestenberg
Subject: Re: [lwip-devel] lwIP UDP and TFTP
Date: Wed, 26 Nov 2003 21:14:51 +0100

Hello,

> Atte Kojo wrote on Wednesday, November 26, 2003 1:49 PM:
>
> > I have to netconn_connect() to the tftp server address:port in
> > order to send a request there.
>
So you explicitly set up a abstract datagram connection which is not
exactly what you want.

> I suspect you use the raw API? If you take a look at the lwip_sendto()
> function in sockets.c, you will see that for an unconnected send (which
> sendto is) the code will do a netconn_connect(), send the packet and do an
> netconn_disconnect() directly afterwards. I would consider this a cleaner
> solution that modifying the code to not set UDP_FLAGS_CONNECTED.
>

Yes, this is the clean approach. Use the *_sendto() functions.

> Coming to think of it, has anyone ever checked if this could lead to a
race
> condition causing packet loss when an interrupt delivers an incoming
packet
> while UDP_FLAGS_CONNECTED is still set?
>
The lwIP is full of race conditions, at least half a year ago. I do not
trust the
lockings to be fully safe in case one would use the stack in a fully
pre-emptive environment with multi threads driving the stack. We came up
with a couple of scenarios that could result in data corruption;
unfortunately
I have not documented the scenarios.

Our solution, in combination with the uCOS-II RTOS was to implement
VERY coarse grained locking. Basically, a priority-inheriting mutex for
locking the whole lwIP stack.

The receive interrupt merely wakes up the task that is responsible for
reading
the packet from the link chip.

In less strict environments, the sys_arch locking might work.

Regards,

Leon.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]