Re: RE : [lwip-users] managing storage problems.

[address@hidden]

Frédéric BERNON schrieb:
> This is a lwIP problem: you should never got a full mbox, due to the lwIP design. But, 
> mainly, when a mbox is full, this is the netconn::recvmbox, or the tcpip.c::mbox (other 
> mailboxes are used like "semaphores").
>   
But I think that's a problem we could solve. As I understand it, it's 
not a problem for TCP because the recvmbox of TCP will never hold more 
data than the TCP receive window (it still could be a problem if data is 
coming in many small packets -> many pbufs on the recvmbox, but if data 
is coming in small packets, the application supposedly will have the 
time to process the data).

For UDP, this can be solved much like the TCP send way by having two limits
a) number of bytes in the recvmbox (like tcp_pcb->snd_buf) and
b) number of pbufs in the recvmbox (like tcp_pcb->snd_queuelen)

I think this is a common problem for UDP stacks (other stacks implement 
SO_RCVBUF, for example) and should be implemented in lwIP also.

The tcpip-mbox is a different thing, because it is very special to lwIP. 
I have code to stop filling the tcpip-mbox when it is too full (which 
disables my RX interrupt also). Then I get informed of the tcpip_thread 
when there is enough space again, so I can turn on RX interrupts again. 
This isn't very portable, but maybe just informing the app/driver about 
high-/low-water-mark could be a more general solution (to prevent having 
to modify the core code for this purpose).

Anyone else needing this except me and shai?

> If you know the full mbox is always an UDP one, I think you can directly use 
> netbuf_delete on the pointer you have to post. It's not a clean solution, but 
> should work.
>   
That's really not a clean solution since memp_free() doesn't check 
whether the pointer to be freed is a pool element (memory region is not 
checked), which could lead to bugs that are hard to locate if the tcpip 
mbox really gets full some time.

Simon