[lwip-users] TCP_LISTEN_BACKLOG setting problem
Mrutyunjay
I am using lwip (STABLE-1.3.2) in two different f/w with rtthreads on TI luminary processor LM3S6965.
I am not able to restrict listen queue to zero ( I need only one active connection on listening socket)
1. using blocking api . if i set MAXCLIENT = 0
if i set TCP_LISTEN_BACKLOG 0 , I can see 1 active connection and 8 in queue , 9th connection is rejected.
if i set TCP_LISTEN_BACKLOG 1 , I can see 1 active connection and 1 in queue.
I am passing MAXCLIENT for listen queue as follows
listen(server_socket, MAXCLIENT) == -1) // control the listen queue accordingly note use : 0 for blocking 1 for non blocking f/w
---------------code snippet ---------------
#define MAXCLIENT 0 // only one active connection.
#define OFFLINE_PORT 5000 // listen on tcp 5000 port
if ((server_socket = socket(AF_INET, SOCK_STREAM, 0)) == -1)
{
!sock error handling !
}
/* Local Setting to receive connection
* initialize the server address (LM Module as Server)
*/
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(OFFLINE_PORT);
server_addr.sin_addr.s_addr = INADDR_ANY;
rt_memset(&(server_addr.sin_zero),8, sizeof(server_addr.sin_zero));
/* bind the connection on specified port to ANY Local IP address
* i.e bind the socket to server address
*/
if (bind(server_socket, (struct sockaddr *)&server_addr, sizeof(struct sockaddr)) == -1)
{
/* Bind fails Error handling !
}
/* Listen on Socket
* Keep Server on listening mode
*/
if (listen(server_socket, MAXCLIENT) == -1)
{
// Listen error handling
}
while(1) // wait for connection
{
//save one level stack
sin_size = sizeof(struct sockaddr_in);
/* connection socket accepts a client request,
* this function call is a blocking type
*/
connected = accept(server_socket, (struct sockaddr *)&client_addr, &sin_size);
/* returns a successful connection socket */
/* Accept the return of client addr point to client's address information*/
rt_kprintf("\nI got a connection from (%s , %d)\n",
inet_ntoa(client_addr.sin_addr),ntohs(client_addr.sin_port));
while(1) // read and process responce from client until disconnected or sock error
{
bytes_received = read_bytes_from_socket(connected,(unsigned char *)&request_header.header,sizeof(request_header.header));
if(bytes_received <= 0)
{
lwip_close(connected);
break ; // get out of connected loop processing and wait for next connection .
}
else
{
// process incomming data and respond to clients .
}
} // end while client connected
}// End while // wating for conection loop
---------------
2. using non blocking api (select ,read ,write )
if i set TCP_LISTEN_BACKLOG 0 or 1, I still get 8 queue connections
Regards,
Mrutyunjay B Patel
Regards,
Mrutyunjay B Patel
Simon Goldschmidt
Mrutyunjay <mruty...@mrutyunjay.com> wrote:
> if i set TCP_LISTEN_BACKLOG 0 , I can see 1 active connection and 8 in
> queue , 9th connection is rejected.
Setting TCP_LISTEN_BACKLOG==0 means "disabled". In this case, backlog is limited by the number of PCBs.
> if i set TCP_LISTEN_BACKLOG 1 , I can see 1 active connection and 1 in
> queue.
In lwIP, the listen backlog is the number of incoming connections queued for accept(), meaning once you accepted one connection, another one is free to be queued for the next accept call. Open client connections previously accepted do not count in here.
SWimon
--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
Martin Velek
have no effect because of this check.
tcp_listen_with_backlog(struct tcp_pcb *pcb, u8_t backlog)
{
/*...some code...*/
#if TCP_LISTEN_BACKLOG
lpcb->accepts_pending = 0;
lpcb->backlog = (backlog ? backlog : 1);
#endif /* TCP_LISTEN_BACKLOG */
/*...some code...*/
}
Obviously zero is not a proper value. Everytime, one client will wait.
If you want only one client, you have to close the listen socket after
accepting a connection and then reopen it. Ugly way, has anyone a
better idea?
Regards
Martin
Mrutyunjay
from comment in lwipopt.h is only a flag to enable backloging option to tcp listening ports ,
not the count of listning as you are saying,
The count of listning queue should be controlled by the second parameter in the listen socket API,
/* Listen on Socket
* Keep Server on listening mode
*/
if (listen(server_socket, MAXCLIENT) == -1)
* TCP_LISTEN_BACKLOG: Enable the backlog option for tcp listen pcb.
*/
#define TCP_LISTEN_BACKLOG 0 //Default = 0 == off
also the call flow follows to following net conn api
the comment says
/**
* Set a TCP netconn into listen mode
*
* @param conn the tcp netconn to set to listen mode
* @param backlog the listen backlog, only used if TCP_LISTEN_BACKLOG==1
* @return ERR_OK if the netconn was set to listen (UDP and RAW netconns
* don't return any error (yet?))
*/
err_t
netconn_listen_with_backlog(struct netconn *conn, u8_t backlog)
Regards,
Mrutyunjay B Patel
Simon Goldschmidt
Mrutyunjay <lw...@mrutyunjay.com>
> from comment in lwipopt.h is only a flag to enable backloging option to
> tcp
> listening ports ,
> not the count of listning as you are saying,
Where was I saying that? I only said that if this feature is turned off, there's another limit somewhere else (the amount of available memory in this case).
> The count of listning queue should be controlled by the second parameter
> in
> the listen socket API,
Did I say anything that contrasts to this?
Simon
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
Mrutyunjay
Thanks for the insight ,
I also came across this in opt.h
/**
* The maximum allowed backlog for TCP listen netconns.
* This backlog is used unless another is explicitly specified.
* 0xff is the maximum (u8_t).
*/
#ifndef TCP_DEFAULT_LISTEN_BACKLOG
#define TCP_DEFAULT_LISTEN_BACKLOG 0xff //default=0xff
#endif
and
/**
* MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections.
* (requires the LWIP_TCP option)
*/
#ifndef MEMP_NUM_TCP_PCB_LISTEN
#define MEMP_NUM_TCP_PCB_LISTEN 8 //default=8
#endif
in the case of 0 is a invalid value then the lwip should default to TCP_DEFAULT_LISTEN_BACKLOG but not 1
also i thinlk 0 is a valid value ,I have used it before in some previous projects under linux bsd and wince.
I will check again MIN and MAX values of backlog ,
somebody let me know will this it affect anything if I remove ths check.
from BSD manual
----------
If the back_log parameter specifies a value greater than the maximum {SOMAXCONN} allowed, the specified value will be ignored and SOMAXCONN will be used. If the back_log parameter specifies a negative value, the specified value will be ignored and zero will be used.
----------
Regards,
Mrutyunjay B Patel
Kieran Mansley
> If the *back_log* parameter specifies a negative value, the
> specified value will be ignored and zero will be used.
Please file a bug. We are ignoring it if it's zero. We should be
ignoring it if it's negative. I'm not sure how complex this will be
internally to fix.
However, as others have pointed out, this shouldn't stop you restricting
the number of accepted connections to 1. You just won't be able to
restrict it to zero.
Kieran
Simon Goldschmidt
Kieran Mansley <kie...@recoil.org> wrote:
> However, as others have pointed out, this shouldn't stop you restricting
> the number of accepted connections to 1. You just won't be able to
> restrict it to zero.
I'm not sure our backlog can provide what he wants. From reading his mails, he wants to limit a listening port to allow only 1 connection at a time, thus denying new connections until the first one is closed.
However, our backlog implementation limits the accept queue, thus allowing unlimited simultaneous connections if the application accepts them fast enough. He would thus end up with 1 active connection and 1 connection queued in the accept-queue.
I'm not too familiar with other OSes, but I think we're pretty much standard here?
Simon
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
_______________________________________________
Kieran Mansley
> He would thus end up with 1 active connection and 1 connection queued
> in the accept-queue.
Yes, that's what I was trying to get at. We don't at the moment support
limiting to 1 active and 0 queued, but 1 active and 1 queued should be
possible. The original email seemed to suggest he couldn't even get it
to limit at that.
Kieran