Re: [lwip-users] Problem re-opening listening pbc

[Keith Rubow]

Yes, I already tried calling tcp_abort() from the accept callback and 
returning ERR_ABRT. The problem is that the connection has already been 
accepted before the accept callback is called, so the result is that 
connection attempts beyond the max number allowed are accepted (the 
connection opens), and are immediately closed (aborted with RST frame). 
This is not what I desire. I would like to have additional connection 
attempts to be refused. I can achieve this behavior only by closing the 
listening pcb once I reach the max number of connections, but then I 
can't re-open the listening pcb until ALL open connections are closed. 
But some connections might stay open indefinitely, in which case I can 
never open the listening pcb again.

Keith Rubow

On 5/12/2018 3:13 AM, Jens Nielsen wrote:
> Can't you just return an error from the accept callback (or 
> tcp_abort() followed by return ERR_ABRT like the default accept 
> callback does) when your max number of connections is reached? I 
> haven't tried this myself but from the looks of it at least the 
> connection shouldn't time out
>
> Your bind to the listening port number fails because the local port is 
> already used by the active connections, you might get past that by 
> setting SOF_REUSEADDR but I'm on thin ice now so maybe someone more 
> into this can clarify...
>
> BR /Jens
>
> On 2018-05-12 00:44, Keith Rubow wrote:
> > I tried the backlog feature (not very well documented). I put #define 
> > TCP_LISTEN_BACKLOG 1 in my lwipopts.h file. I changed tcp_listen() to 
> > tcp_listen_with_backlog(), passing it the maximum number of 
> > simultaneous connection I want. I added tcp_backlog_delayed() to my 
> > accept callback. I added tcp_backlog_accepted() before tcp_close() 
> > when the connection was closed in either the receive data callback 
> > (with p=NULL), or when my application times out the connection.
> >
> > This does limit the number of connections that can be opened 
> > simultaneously. However, once the limit is reached, additional 
> > connection attempts are not refused (which is what I would prefer), 
> > rather the connection attempts simply time out. Still, this might be 
> > better than my initial approach of aborting additional unwanted 
> > connections, which resulted in the connection opening, but 
> > immediately closing again.
> >
> > Still, the question remains why lwip will not allow binding to a port 
> > number that has no current listening pcb, but does have one or more 
> > open connections. I don't understand why this would cause a problem.
> >
> > Keith Rubow
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users