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

[shai katzir]

I'm using the 1.2.0 stable version, and i would preffer to stay with it, at
least until 1.3.0 will be out..

Currently I'm using the UDP only, but i intend to use the TCP or maybe other
features in the future.
therfore, freeing the packet within the sys_mbox_post won't work for me.

In this case, I'm afraid i'll have to make slight changes in the lwip I'm
using.
Changing the mbox (as you mentioned) to return errors, is quite heavy and
may be risky for me
to add to the stack.
I'm thinking about changing the operational logic of the UDP stack, by not
allowing any packets to 
be received (into the recvmbox) if the socket is not trying to receive (by
recvfrom..).
for this i need to know two things:
1. where can this problem accure except from the udp recvmbox (you mentioned
that it can't happen
   in the tcp, but can happen in the tcpip reqs mbox?)
2. where should i drop this packet? how can i check if the socket is on
receive and drop the packet?

as for simon suggestion:
>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) 
do you mean adding the current situation of the recvmbox (total len, and cur
len) to the pcb as an additional attribute?
I think that if you want to be able to get this information in the stack
(the mbox situation) it should be
an integral part of the sys_mbox like BERNON mentioned (adding sys_mbox_len
or sys_mbox_is_full).

shai
-- 
View this message in context: 
http://www.nabble.com/managing-storage-problems.-tf4716993.html#a13487601
Sent from the lwip-users mailing list archive at Nabble.com.