Problem with lwip_select under Nucleus

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with lwip_select under Nucleus

brivero

First of all I would like to thank you very much for your help.

Next, I would like to explain the scenario in which the problem takes place. I have found a standard Unix-sockets code in a book and I have implemented it for Win32 with no problem. Since the objective is to create a wrapper socket API in order to work with a few OSs (Win32, LWIP&Nucleus,...), I tried to do the same for LWIP. The structure of the application is as follows:

Server                     Client
======                    ======
socket
bind
listen
                             socket
                          connect <server>
accept    
send

                         recv
socket_delete


This daytime application works in Win32 (both server and client in Win32) with no problem. But in LWIP(server in Win32 and client in LWIP), before the server sends the packet, the client ends the program closing the connection. This way, the client finds nothing to receive, and the server has no connection for when he is going to execute the send statement, causing a send error.

At this point, I supposed that for default, sockets in LWIP were non-blocking (is this true???), and in consequence, the lwip_recv() worked as non blocking. That would be the reason for which it would not wait for the server to send, and the client execution would finish before the server send statement.
Introducing a one second sleep statement just before lwip_recv() all worked ok.

That´s why I tried to implement a blocking recv() by calling select just before recv(). But In spite of the 5 seconds timeval structure used as input to this select, it did not wait. I used this select looking at the readset in which the socket used to receive was set. At first I was afraid that there was some kind of problem with the semaphores, dealing with the port to Nucleus or something like that. But I have had a close look at some other select calls, and as long as there is not a connect before, they work perfectly waiting the timeval value etc.

I have gone into the select by debugging, and the execution changes in sys_sem_wait_timeout(in sys.c). This function returs a 1 when it does not wait, and a 0 if it does wait. Inside this function, the problem is in the sys_timeout function, as it does let the sswt_cb.timeflag with a 0 value when it does not wait, while it changes its value to 1 when it waits.

I cannot find an explanation to what happens, but actually, select does not wait when it is called after a connect. I would be very pleased if somebody could give me some advice.

Regards,

Borja.
_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with lwip_select under Nucleus

Kieran Mansley
On Fri, 2007-05-25 at 09:54 +0200, [hidden email] wrote:

> At this point, I supposed that for default, sockets in LWIP were non-
> blocking (is this true???),

No.  By default socket operations are blocking.  I assume you haven't
specified MSG_DONTWAIT in the flags to the recv operation, or O_NONBLOCK
to the socket options.  These would both result in non-blocking sockets.

> I cannot find an explanation to what happens, but actually, select
> does not wait when it is called after a connect. I would be very
> pleased if somebody could give me some advice.

It sounds like there's a problem with your port that is causing the
blocking operations in the sockets API to not block.  For some reason
lwIP is behaving as if there is data to read on that socket, when in
fact there is none.

Ignore select() for now as I think if we can solve the simpler recv-not-
blocking issue, that will be a good start.

Take a look at the lwip_recvfrom() function.  Can you check the
following when you call it by adding some extra debugging:
 - that sock->lastdata is NULL.
 - that buf returned by netconn_recv() is NULL.

If that is the case, take a look at netconn_recv().  This can return
NULL for all sorts of reasons.  Add debugging (e.g. a printf) to each
one and see which case is failing.

With that information we should be able to work out what's wrong.

Kieran





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE : Problem with lwip_select under Nucleus

Frédéric BERNON
In reply to this post by brivero
Same question than the last time: which release? Even if a "connect" should do an implicit "bind", can you test to call it (bind) before connect?
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : lwip-users-bounces+frederic.bernon=[hidden email] [mailto:lwip-users-bounces+frederic.bernon=[hidden email]] De la part de Kieran Mansley
Envoyé : vendredi 25 mai 2007 10:15
À : Mailing list for lwIP users
Objet : Re: [lwip-users] Problem with lwip_select under Nucleus


On Fri, 2007-05-25 at 09:54 +0200, [hidden email] wrote:

> At this point, I supposed that for default, sockets in LWIP were non-
> blocking (is this true???),

No.  By default socket operations are blocking.  I assume you haven't specified MSG_DONTWAIT in the flags to the recv operation, or O_NONBLOCK to the socket options.  These would both result in non-blocking sockets.

> I cannot find an explanation to what happens, but actually, select
> does not wait when it is called after a connect. I would be very
> pleased if somebody could give me some advice.

It sounds like there's a problem with your port that is causing the blocking operations in the sockets API to not block.  For some reason lwIP is behaving as if there is data to read on that socket, when in fact there is none.

Ignore select() for now as I think if we can solve the simpler recv-not- blocking issue, that will be a good start.

Take a look at the lwip_recvfrom() function.  Can you check the following when you call it by adding some extra debugging:
 - that sock->lastdata is NULL.
 - that buf returned by netconn_recv() is NULL.

If that is the case, take a look at netconn_recv().  This can return NULL for all sorts of reasons.  Add debugging (e.g. a printf) to each one and see which case is failing.

With that information we should be able to work out what's wrong.

Kieran





_______________________________________________
lwip-users mailing list
[hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users

=?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?= (810 bytes) Download Attachment