[lwip-users] socket functionality - nonblocking?

[Micael]

Hi all,
this is my first post to this list. :)

I am trying to understand what separates lwip from the full BSD socket
interface in order to see if I can use lwip in my new project as I would
like. I have previously used interniche stack but if remotely possible,
I'd like to switch to an open solution this time.

I could not find such information anywhere, but some fragments from this
list, and also by looking into the code (which I have not dug too deep
into yet).

Basically, I need non-blocking connect, recv, select and listen.

[Kieran Mansley]

Post by Micael
Basically, I need non-blocking connect, recv, select and listen.

[Piero 74]

I'm not sure if you can put a listening socket in the
readable set and get notified when a new connection arrives either -
perhaps someone else has recent experience of this.

yes... it's possible... i use it in my code... my task loop using a select
normally with only listener sockets, adding a open socket when a connection
is accepted.
It works very well.

Piero

[Micael]

I'm not sure if you can put a listening socket in the
readable set and get notified when a new connection arrives either -

yes... it's possible... i use it in my code... my task loop using a ..
It works very well.

Thanks guys!

I understand that there are reasons for not supporting non-blocked io, but
are there any plans or work in progress regarding this? Or doesn't the
current infrastructure lend it self to this easily?
I guess it must have been discussed before. I saw some old posts about a
socket2.c?


I am now at the cross section with the sign saying Left "lwip" Right
"commercial IP stack". :)

If I choose lwip, I guess I will have to either do some implementation
outside the socket layer, or try to help the development of lwip in the
non-blocking way.


Background:
I like the socket api, because of its portability, and almost all my
designs are a bunch of nodes that has open connections to many other,
non-blocking is crucial for me. In this design, I would use lwip with
freertos.org on an NXP arm7tdmi.


Micael

[Simon Goldschmidt]

Post by Micael
I understand that there are reasons for not supporting non-blocked io, but
are there any plans or work in progress regarding this? Or doesn't the
current infrastructure lend it self to this easily?

This always bugs me, too. Not that I need it right now, but I think this is still a major downside of the lwIP sockets implementation if compared to other stacks.

The main problem with nonblocking IO is that someone has to implement it. Currently, there are 4 'active' developers maintaining lwIP (plus some for documentation) and none of us seem to currently use nonblocking IO :-(

Post by Micael
I guess it must have been discussed before. I saw some old posts about a
socket2.c?

Hehe, socket2.c is an idea started by Frédéric and me to speed up sockets on lwIP. The main goal was to prevent sockets using netconn but directly using the raw API. My preference would be to implement normal socket functions and fast functions that resemble the netconn API advantages so that we would only have to maintain 2 APIs in the far future. But that's not going to happen soon, I guess.

Writing this, if it was me who fixed nonblocking IO, I guess I'd write sockets2 first and then implement nonblocking IO on it... ;-)

Post by Micael
I am now at the cross section with the sign saying Left "lwip" Right
"commercial IP stack". :)

Well, I guess we all came across that... Don't let marketing confuse you too much! ;-)

Post by Micael
If I choose lwip, I guess I will have to either do some implementation
outside the socket layer, or try to help the development of lwip in the
non-blocking way.

Of course, help is always welcome! Implementing nonblocking IO for the current sockets API should not be that tricky, since there is not that much work left, I think: after all, some nonblocking calls are already supported...


Simon

[Piero 74]

OH! what's nice news!
Welcome Micael!

I did the first release of my board using nxp arm7 too (lpc2365) and PHY
chip from smsc.
In the past i had to decide the same:
(commercial RTOS + commercial TCPIP stack) OR (freeRTOS + LWIP)

i decided for open source choice...
i did some additional work for writing emac driver by myself, sys_arch and
ethernetif layer for lwip+freertos, and i spent more time for debug, and...
my project became delayed...., but today i think yet that i choosed the
better solution, for cost saving, for flexibility, for a great comunity of
developers behind freertos and lwip, and now i have more knowledge about
TCPIP stack!


i saw in the past posts about socket2.c too.... i don't know who is working
on it...
i'm interested on it, because i'd like to work with non-blocking calls (this
is the reason because i used select in my tcp manager task)... i want to be
sure that every task in my code never block (so... each task "kick" a
watchdog manager, and if one is blocked, after few dozen of seconds the
board will reset itself)
My dream is a new socket layer for lwip, with the possibility to expand it
with custom functions, to bring in socket other data stream (i.e. packets
from serial, or from rtos queue...). In this way i could only used select
function with all kind of data stream (i like it).

Actually, i have in my code a task which works in this way

while(1)
__wait_on_select (timeout = 50 ms for example)
__if_select_set_from_listener
______accept_connection_and_put_sd_in_select
__if_select_set_from_opensocket
______manage_data_FROM_socket
__wait_on_q (timeout = 0!!!!)
__if_data_from_q
____send_data_TO_socket


but, in this way, i have code which unlock immediately when a packet arrives
from socket, but instead can send packets from other tasks polling the queue
every 50 ms (or less, if another packet unlock the select before)

i'd like to have something like a select for packet from NET sockets and
QUEUE socket!


if you want, we can share our experience, with stack and application code
which use bsd socket!

Bye,
Piero

Post by Micael

I'm not sure if you can put a listening socket in the
readable set and get notified when a new connection arrives either -

yes... it's possible... i use it in my code... my task loop using a ..
It works very well.

Thanks guys!
I understand that there are reasons for not supporting non-blocked io, but
are there any plans or work in progress regarding this? Or doesn't the
current infrastructure lend it self to this easily?
I guess it must have been discussed before. I saw some old posts about a
socket2.c?
I am now at the cross section with the sign saying Left "lwip" Right
"commercial IP stack". :)
If I choose lwip, I guess I will have to either do some implementation
outside the socket layer, or try to help the development of lwip in the
non-blocking way.
I like the socket api, because of its portability, and almost all my
designs are a bunch of nodes that has open connections to many other,
non-blocking is crucial for me. In this design, I would use lwip with
freertos.org on an NXP arm7tdmi.
Micael
_______________________________________________
lwip-users mailing list
http://lists.nongnu.org/mailman/listinfo/lwip-users

[Rishi Khan]

listen is blocking? Maybe you mean accept? In any case, I have code
that makes accept non-blocking and I sent it in as a patch before ...
not sure if it made it's way to the CVS repository.

Rishi

Post by Micael
Basically, I need non-blocking connect, recv, select and listen.

[Kieran Mansley]

Post by Rishi Khan
listen is blocking? Maybe you mean accept? In any case, I have code
that makes accept non-blocking and I sent it in as a patch before ...
not sure if it made it's way to the CVS repository.

Yes, sorry, I meant accept.

Kieran

[Micael]

Post by Kieran Mansley

Post by Rishi Khan
listen is blocking? Maybe you mean accept? In any case, I have code
that makes accept non-blocking and I sent it in as a patch before ...
not sure if it made it's way to the CVS repository.

Yes, sorry, I meant accept.

This makes me feel good. ;-)

So if I have collected all information correctly, non-blocking status is
something along the lines of;

Nonblocking support:
---------------------
select() (also have a working timeout support)
recv()
listen()
accept() - using patch from Rishi

Missing Nonblocking support for:
---------------------------------
connect()
send()



Micael

[Rishi Khan]

I think send is non-blocking always. yes/no??

Rishi

Post by Micael

Post by Kieran Mansley

Post by Rishi Khan
listen is blocking? Maybe you mean accept? In any case, I have code
that makes accept non-blocking and I sent it in as a patch
before ...
not sure if it made it's way to the CVS repository.

Yes, sorry, I meant accept.

This makes me feel good. ;-)
So if I have collected all information correctly, non-blocking
status is
something along the lines of;
---------------------
select() (also have a working timeout support)
recv()
listen()
accept() - using patch from Rishi
---------------------------------
connect()
send()
Micael
_______________________________________________
lwip-users mailing list
http://lists.nongnu.org/mailman/listinfo/lwip-users

[Kieran Mansley]

Post by Rishi Khan
I think send is non-blocking always. yes/no??

No. Sometimes it will need to wait for space in the send queue. It
will, I think, always be non-blocking if you know the send queue is not
full.

Kieran

[g***@gmx.de]

Post by Kieran Mansley

Post by Rishi Khan
I think send is non-blocking always. yes/no??

No. Sometimes it will need to wait for space in the send queue. It
will, I think, always be non-blocking if you know the send queue is not
full.

I would have thought it is always blocking, since it at least has to
change tasks to tcpip_thread and back again? Of course, it depends on
the definition of 'blocking'... However, I don't know if we have a
completely nonblocking send that just puts the data on a queue... For
that, we would have to support sending pbufs with TCP (in contrast to
data pointer as it is now).

Simon

[Jonathan Larmour]

listen is blocking? Maybe you mean accept? In any case, I have code that
makes accept non-blocking and I sent it in as a patch before ... not
sure if it made it's way to the CVS repository.

It did, so accept does indeed support non-blocking mode in CVS (but not in
lwIP 1.3.0).

The basics of non-blocking connect() are simple - it's doing the proper
error handling that is a little bit trickier. That means not letting the
socket be fully usable until connected, setting the correct error codes
such that getsockopt(SO_ERROR...) works, and posting an API event so that
select would wake up. That probably also means changing alloc_socket to
initialise sendevent to 0.

Non-blocking send should be very easy I would have thought. Just check for
sock->sendevent==0 in lwip_send() before calling netconn_write(). I would
have thought anyway.

Jifl

[Rishi Khan]

FYI, a secondary problem with non-blocking connect is that if the
server is not available or doesn't send RST packets for closed
connections, you will back off on each retransmit and it may take a
while to connect to the server once it is up. Imagine if you are
backed off far enough that you are sending one SYN packets per minute
and the server comes up in the middle of that.

The problem with non-blocking connect is that a lot of state needs to
be kept to continue to retry the connection. For select, accept, and
recv, you just need to look in the queue, see nothing there, and return.

Rishi

Post by Micael
Hi all,
this is my first post to this list. :)
I am trying to understand what separates lwip from the full BSD socket
interface in order to see if I can use lwip in my new project as I would
like. I have previously used interniche stack but if remotely
possible,
I'd like to switch to an open solution this time.
I could not find such information anywhere, but some fragments from this
list, and also by looking into the code (which I have not dug too deep
into yet).
Basically, I need non-blocking connect, recv, select and listen.

[Micael]

Post by Rishi Khan
FYI, a secondary problem with non-blocking connect is that if the
server is not available or doesn't send RST packets for closed
connections, you will back off on each retransmit and it may take a
while to connect to the server once it is up. Imagine if you are
backed off far enough that you are sending one SYN packets per minute
and the server comes up in the middle of that.

Yes, the way I do it, is that I have a thread that constantly tries to
connect to the other servers, while also having a listen port open; the
one first, or if simultaneously, with higher tcip address wins. Once
connected, I keep the connection forever.
This means using getsockopt() (SOL_SOCKET, SO_ERROR) for checking if the
connect() where good or not, once the fdset reports activity on the
connect socket.

Post by Rishi Khan
The problem with non-blocking connect is that a lot of state needs to
be kept to continue to retry the connection. For select, accept, and
recv, you just need to look in the queue, see nothing there, and return.

Yes, I know! :) It can be quite complicated to manage all the states, but
I know of no other way, if one wants to keep it all within the same
thread. But that's partly why I want socket API, it is so much easier to
do the development on my PC (linux); just add some 20 virtual ethernet
interfaces,start as many instances of your "device code" on the PC as you
like, and once it works the way intended, move the code to a bunch of real
targets.


Micael

[Micael]

Post by Simon Goldschmidt
The main problem with nonblocking IO is that someone has to implement it.

:-) Same old problem.

Post by Simon Goldschmidt
Hehe, socket2.c is an idea started by Frédéric and me to speed up

sockets on lwIP. The main goal was to prevent sockets using netconn but
directly using the raw API.

Can you develop that a little bit? Are there any known bottlenecks in the
code, or are you simply after a less cpu intensive solution?

Post by Simon Goldschmidt
My preference would be to implement normal socket
functions and fast functions that resemble the netconn API advantages so

that we would only have to maintain 2 APIs in the far future. But that's
not going to happen soon, I guess.

And the reason being the performance issues you mention above?

Post by Simon Goldschmidt

Post by Micael
I am now at the cross section with the sign saying Left "lwip" Right

"commercial IP stack". :)

Post by Simon Goldschmidt
Well, I guess we all came across that... Don't let marketing confuse you

too much! ;-)

I have already turned right a few times now, certainly spent a lot of
money and effort 'over there', and I therefore hope that turning left is a
better long term solution for me, but that obviously depends on how high
the mountain is to climb.



Thanks,
Micael