Re: [lwip-users] socket functionality - nonblocking?

[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

On Nov 24, 2008, at 10:52 AM, Micael wrote:

> 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.
>
> From what I gather from various posts on this list, connect() maybe  
> does
> not do non-blocking, and I therefore assume that maybe recv doesn't
> either. This part is a bit hard to read out from the code, being  
> new to
> this stack.
>
> However, looking into the code, afaics, select() does seem tom support
> non-blocking and timed blocking, so I thought that I should ask  
> just to
> make sure that I got it right.
>
>
>
> thanks,
>  - Micael
>
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users