I'm developing a custom http/websockets server using libuv.  After long 
periods of time, the server seems to become unresponsive to new 
connections.  It is my hope that I can use the uv_tcp_keepalive function to 
detect any failed connections and clean up their resources, and that I can 
design around this behavior to get a more responsive server.

I'm wondering two things:

1) if I can rely solely on the uv_tcp_keepalive function to detect failed 
connections.  If so, how do I get notified by libuv when the tcp keepalive 
detects a failed connection?  It'd seem like there should be a callback for 
this, but I can't find one.

2) Why is tcp keepalive showing the strange behavior described below???   
If I can't figure that out, its a deal-breaker for #1.  I can't have the 
server not responding to incoming connection requests. 

When I enable uv_tcp_keepalive, I see strange behavior. If the server 
closes a connection with a client, it will no longer accept any new 
connections from that machine.  

I can see this when I open two connections in different browser tabs, and 
put one of them in the background.  Presumably the browser slows that 
connection somewhat and I have logic (different from the tcp_keepalive) at 
the application level to detect a failure to send a heartbeat in a given 
interval.  When it does, the server closes that client TCP/Websocket 
connection, and cleans up the UV handle.  From that point forward, I can no 
longer connect to the server from that machine.  It is as if the 
tcp_keepalive setting is not releasing resources (the port?) when the uv 
handle is cleaned up.  

This behavior is not exhibited when I disable uv_tcp_keepalive.

Thank you for any insights you can provide!

ST

-- 
You received this message because you are subscribed to the Google Groups 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to