[lwip-users] 1.4.0.rc1: How to use netconn-API for non-blocking connect?
Benjamin Schelte
Dear all,
I am currently integrating the first release candidate of lwIP 1.4.0 into my project, because I need non-blocking connect support.
As I could not find any example sources or documentation about this feature I tried it on my own, but so far I could not succeed.
My setup is the following:
lwIP v1.4.0.rc1
RTOS
Netconn-API
The sequence I use to connect to another device in non-blocking mode is basically the same as previously with one difference:
…
psNetconn = netconn_new(NETCONN_TCP); // New tcp connection
netconn_set_nonblocking(psNetconn, TRUE); // Don't block!
if (psNetconn != NULL) {
eError = netconn_connect(psNetconn, &sPeerIPAddress, (u16_t)usPort);
if (eError == ERR_OK) {
// Connection established, create request
…
}
else {
// Connection error, Reset connection and task status
…
}
else {
// Connection error, Reset connection and task status
…
}
…
// Close and delete the connection
if (psNetconn != NULL) {
netconn_close(psNetconn);
netconn_delete(psNetconn);
psNetconn = NULL;
}
…
So the only addition in my code is the line below netconn_new: netconn_set_nonblocking().
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).
Could anyone of the developers please give me some advice in how to use the non-blocking connect feature, or how it is supposed to work?
I don’t even know, if the mechanism I use is intended to be solution for the non-blocking connect though.
Thanks in advance.
Best regards,
Benjamin
gold...@gmx.de
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).
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
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
Kieran Mansley
>
> 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.
Your code seems a bit odd - perhaps this is just the way that you've
abbreviated it for your post but:
- you're adding an unconnected socket to the writeset, and then calling
select to wait for it to be writeable. Why? It's not connected, and
so won't be writeable until you call lwip_connect() so any call before
then will timeout as you're seeing.
- the following use of select, after you've written to it and are
waiting for the reply makes much more sense, but you don't seem to have
anything in "fd_readset", so this will probably time out as well.
- I can't remember with select whether the timeout structure is updated
on return. If so you might need to reset the values in tv before each
call.
Kieran
_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users