[lwip-devel] [task #7525] Implement TCP listen backlog

[Simon Goldschmidt]

Follow-up Comment #15, task #7525 (project lwip):

> #if LWIP_LISTEN_BACKLOG
> # define LWIP_MAX_LISTEN_BACKLOG LWIP_LISTEN_BACKLOG
> #else
> # define LWIP_MAX_LISTEN_BACKLOG 1
> #endif
> 
> err_t netconn_listen_with_backlog(struct netconn *conn, int backlog);
> #define netconn_listen(conn) netconn_listen_with_backlog(conn,
LWIP_MAX_LISTEN_BACKLOG); 

That would change the existing behaviour from allowing a maximum number of
connections to only one connection... I don't know if that's good or not: it
could break existing applications but it prevents overflooding an
acceptmbox...

> For "to_accept", how about "accepts_pending" 

But raw API apps can't have any accepts pending, can they? How would a raw
API app work with this new feature? Since 'to_accept' is increased in
tcp_listen_input, would raw API apps decrease it in their accept callback? So
'to_accept' it would always be 0 or 1 for raw API apps? If it's like that, why
don't we include the counter in the netconn part and only have a flag
'accept_allowed' in the raw part? To me it feels kind of weird including the
counter in the pcb when it can only be used in the netconn API (unless I'm
wrong with that assumption, of course :)

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?7525>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/