RE: [lwip-users] 1.4.0.rc1: How to use netconn-API for non-blocking connect?

[Benjamin Schelte]

I have a couple of questions about the socket handling in lwIP or maybe socket handling in general. I already tried to figure it out on my own by reading tutorials in the internet, but so far I could not succeed.

I changed my client code to use socket-API instead of netconn-API and I am utilizing the “select” function to get a kind of non-blocking behavior.

The way it should work is the following:

1.       Try to connect to a device with a specific timeout

2.       Send data to that device

3.       Wait for the answer and receive data

4.       Close socket

 

This is an excerpt of the code I am using to do so:

 

iSocket = lwip_socket(AF_INET, SOCK_STREAM, 0);      // TCP

 

FD_ZERO(&fd_writeset);

FD_SET(iSocket, &fd_writeset);

tv.tv_sec = 3;

tv.tv_usec = 0;

 

iRetVal = lwip_select(iSocket + 1, NULL, &fd_writeset, NULL, &tv);

if (iRetVal != -1) {

      iRetVal = lwip_connect(iSocket, (struct sockaddr*)&addr, sizeof(struct sockaddr_in));

}

else {

…

}

if (iRetVal != -1) {

…

      lwip_write(iSocket, (void*)pcTCPBuf, usStreamLen);

}

…

iRetVal = lwip_select(iSocket + 1, &fd_readset, NULL, NULL, &tv);

if (iRetVal != -1) {

      …

      iRetVal = lwip_recv(iSocket, (void*)pcRecvBuf, STD_CLIENT_MAX_PACKET_SIZE, 0);

      …

}

 

 

In general it is working, but I noticed an odd behavior using the “lwip_select” function.

If I am sending a ping-pong between 2 clients it will hang about 3 seconds between each turn. If I increase the timeout value to 10 seconds it will hang about 10 seconds, etc.

 

It looks like “lwip_select” always stays for the specified time in the function call of “sys_arch_sem_wait()” for some reason. In my opinion it should return either after something arrived for that socket or in timeout case. Am I right with this assumption (I am not so familiar with socket-handling yet)?

It seems like “sys_sem_signal()” is not called in time to inform the select function that some data has arrived on that socket.

 

Can anybody give me a hint, where I can dig to find out if it is either a problem of the lwIP stack in general or a problem of my port.

 

Best regards,

Benjamin

 

 

 

From: address@hidden [mailto:address@hidden On Behalf Of address@hidden
Sent: Tuesday, October 19, 2010 7:12 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] 1.4.0.rc1: How to use netconn-API for non-blocking connect?

 

Benjamin Schelte wrote:

However the call to the function “netconn_connect” always returns ERR_INPROGRESS, but after that nothing more happens.

Neither delaying the task and processing later, nor directly calling “netconn_write” worked (it also returned ERR_INPROGRESS).

Of course it does, that's what you told it to: nonblocking means the call is enqueued (your application thread *does* get blocked a while, but only for the time the lwip-thread needs to enqueue and send the SYN). If this succeeds, ERR_INPROGRESS is returned.

If you were using a socket (instead of a netconn), select would mark the socket as writable. Since you are using a netconn, you will have to implement this on your own: the callback you can pass to netconn_new_with_callback() will be called with enum netconn_evt == NETCONN_EVT_SENDPLUS for your netconn when the connection is established.

However, this can be quite a pain to implement on your own, so you might want to use sockets instead if you can live with the extra copying that API imposes (compared to the netconn API): using sockets, you can simply connect and then wait (with a timeout) using select(), just as you would do on any other socket implementation/OS.

Simon