When a Jardin STREAM server accept()s a new connection, it will setup the polling module to wait for input events on it. Normally, it will get an input event soon specifying that new data is available, and will call recv(); but it may happen that the client is stuck and it doesn't send any data after the stream connection was accepted. In this case, the polling will remain also forever, as there is no connection timeout in the Jardin Server. In Multi-threaded servers this may get even worse, as each new connection is processed by a thread in the internal thread pool, so in this case the whole thread will get stuck in an infinite glib main loop without input events.
Jardin Server should have a jardin_server_set_max_connection_duration() function or something like that, so that if no input data arrives in the given number of seconds, it will close the connection.
After reviewing the problem I think it's not that critical... it can cause a DoS attack but there doesn't seems to be a straight forward (nice and easy) solution. For what I have seen we will have to add an extra timeout watch on the jardin polling module, update it on every reception and if it times out close the connection and destroy the polling module.
Comments?