[Top][All Lists]

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

Re: [lwip-devel] Netconn events?

From: Dirk Ziegelmeier
Subject: Re: [lwip-devel] Netconn events?
Date: Sun, 9 Oct 2016 09:59:12 +0200

I talked to Simon about this at work, because I also have my problems in understanding that code.

What became clear to me is: The main problem is on how you see these events. You and I mostly think of them as mapping accept, receive, send to events, but they are not designed like this.

A better approach to understand them is:

You have three ways to block a client:
- accept mbox (sys_arch_mbox_fetch(&conn->acceptmbox, &accept_ptr, 0);)
- receive mbox (sys_arch_mbox_fetch(&conn->recvmbox, &buf, 0);)
- send queue is full (sys_arch_sem_wait(LWIP_API_MSG_SEM(msg), 0);)

The events have to be seen as events signaling the state of these mboxes/semaphores. For non-blocking connections, you need to know in advance whether a call to a netconn function would block or not, and these events tell you about that.

PLUS events say: Safe to call once. They are counted in sockets - three RCVPLUS events for accept mbox means you are safe to call netconn_accept 3 times without being blocked. Same thing for receive mbox.

MINUS events say: You call to to a possibly blocking function is "acknowledged", sockets decrement the counter.

For TX, there is no need to count, its merely a flag. PLUS means you may send something. A MINUS event occurs when the next call to a netconn_send() would be blocking. PLUS occurs when enough data was delivered to peer so netconn_send can be called again.

I hope this sheds some light on this. This really needs to be documented :-) - if you like, send me a text, I'll commit it.

My explanation is still not perfect, I'm trying to write down what Simon told me at work, but I did not reanalyze the netconn code to see if everything is correct.


On Thu, Oct 6, 2016 at 9:09 PM, Freddie Chopin <address@hidden> wrote:

Is there a specific reason why netconn events cannot be called in a
straightforward way? Why can't we just have events like "received",
"accepted", "acknowledged", "connected", "closed", etc. instead of all
this crazy stuff with "receive plus" meaning almost the same as
"receive minus", both meaning something different depending on whether
length is zero or not (in the former case this event can actually mean

There only explanation of these events that I've found online is on the
eCos website


I must say that this is far from being clear and I really don't get the
difference between "plus" and "minus" variants, not to mention the mess
with receive with zero length...

BTW - would this be possible to have a function/macro to set/clear
callback for a created netconn? For example I'm only interested in
having a callback in the netconn of the connection (returned by
netconn_accept()), not in the one created with netconn_new().

I'm sending this whole message because I've been thinking about doing a
netconn thread that can do non-blocking receive, while other thread
will do infrequent sends (everything serialized with a mutex), together
with the requirement to close the netconn from this second thread,
requires the use of callbacks, but this seemingly trivial thing seems
so extremely complicated (lack of good examples doesn't help), that
I've thought there's a room for improvement here...


lwip-devel mailing list

reply via email to

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