Hi all,

On my application (TCP-server based with callback API) I need to limit the number of TCP connections in this way:

the application keeps a list of connection information structures of limited size; when a client requests a connection, the accept callback searches the list for an empty slot. If all the slots are filled (so the maximum number of connections is reached) the callback searches for the oldest "inactive" connection (if present) and closes it; then assigns the slot to the new connection (a connection is marked as "inactive" after every successful query-response cycle, or after a
timeout).
To make this working, I have to keep a reference to the connection pcb as a parameter of the connection info structure; this reference will be used to close the connection from the accept callback of another connection, as I explained.

But how can I ensure that the reference is still valid when I use it to close the connection? (Of course, I have to free the relative connection info structure when the receive callback is called for a pcb with NULL data...)

Another case in wich I must check the validity of the pcb reference is when I have to send data to the client outside of a callback (in this case I think it is also necessary to know if the connection is in a state that allows transfer of data, but maybe I'm wrong...).

Is it possible to "ask" the TCP stack to check if a pcb reference is still "usable"? Actually, when I have to close a pcb outside of one of its callbacks, I first check if the pcb is referenced in one of the tcp_listen_pcbs, tcp_active_pcbs, tcp_bound_pcbs and tcp_tw_pcbs lists; if the reference is not found, I consider that the pcb is
already deallocated.
Similarly, before I have to call tcp_write outside callbacks, I check for a reference but only in tcp_active_pcbs list.
But I'm not sure that this approach is correct...

Thank you very much

Enrico


_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to