I'm working with a Node library that doesn't explicitly close sockets after it's done with them. Instead it tries to clean up by deleting reference to the socket and letting them be garbage collected.
Googling is failing me: I don't think that is possible for the GC to clean up unclosed sockets. That is, I think that any socket descriptors will still be in use, from the OS's perspective.
Additionally, assuming that I as the library consumer have access to the socket objects, what is the best way for me to close them? I have played around with end(), close(), and destroy() with limited success. Sometimes they seem to block into perpetuity (end/destroy), and other times it seems like the callback is never made (close).
It could be due to the fact that your socket sent a FIN package and hangs up on the connection while waiting for the other end to send the FIN2 message. In cases when the socket on the other side is not nicely closed, your one won't receive any package, thus hanging up forever.
Actually, end sends a FIN packet and does not shutdown the socket.
A possible solution could be to wait for a while on it by means of setTimeout when you invoke the end function, then explicitly destroy it by means of the function destroy. This won't affect your socket if the other end has correctly closed the connection, otherwise it will force the shutdown and all resources should be released.
Related
I have a program that uses ZMQ to send and receive between a C++ application and a Python GUI. The Python sends all commands to the C++ app to do the work, the C++ app periodically sends back status to update the GUI.
The C++ is multi-theaded but we never made the call zmq_send thread safe, so in 1 out of 100,000 runs we'd get an unhandled exception or segmentation fault if two threads tried to send status back to the gui simultaneously. This took longer than I care to admit figuring out since it was so sporadic. This was easily solved with a mutex around zmq_send because the socket is managed by a singleton.
In addition to the processing threads, there is one thread that just idly waits to receive and dispatch commands from the gui using zmq_poll and then zmq_msg_recv when something is available.
The question, can I safely poll the same socket while a send is happening? Most of the time the receive thread is sitting in zmq_poll with a timeout, and sends seem to be happening without issue. I can't seem to find any good documentation about this. I assume a mutex needs to protect zmq_send and zmq_msg_recv from occurring simultaneously, but I am not sure about the safety of polling while sending.
Details about the setup: using PAIR interface with a single client and server. All messages are small (<1KB). There is only one socket shared for sending and receiving.
This is a large, decade old application I'd like to avoid redesigning if possible.
I am writing a proxy app in nodejs which handles thousands of concurrent connections inwards and outwards
I want to make sure all idle and unneeded connections get closed properly and their file descriptors get released. If it leaks file descriptors, I would run out of them very fast.
My question is that :
what is the best solution to make sure a connection gets closed ? socket.end() or socket.destroy() ?
Currently I am using socket.end() but in doc it says it half closes the connection, is there a situation that socket.end() doesn't result in closing a connection ? what I am interested in is releasing the file descriptors ASAP.
So what do you suggest ?
socket.end() is a much better way to gracefully terminate your connections. socket.destroy terminates all of your connections immediately. Also, due to a bug, in most of the cases one had to add socket.end after destroy to make it work.
So end() is the way to go!
I need to perform a cleanup action when the Node process exits.
I know I can use process.on('exit'), process.on('Unhandled|Rejected Exception') and process.on('<signal>') to listen such events.
However, I would like not bind any of this, for these reasons:
If I bind to process.on('exit'), I should not be doing any async operations, which is not reliable when you need to write out a message over a socket or a pipe (afaik).
If I bind to process.on('some exceptions'), I have to print the error like a normal node process. I don't want to reinvent the wheel.
If I bind process("SIGINT"), I have to exit the process manually. What if someone else is listening too, or what if I can't know the exit status of the node process?
Any idea what I should do?
In my particular use case I will spawn a server, and when Node exits, I need to send it a signal to tell it to quit. And I would like this to be as transparent as possible for the module-consumer.
Thanks!
Just let your client process hang up.
In your use case, you mention that you have a socket going from your nodejs module to your server, and you want to kill the server when the module exits because the server has nothing else to do. No matter which way you spin it, there is no foolproof way for a client to tell a server that it's done with them by sending a message (since the client can die unexpectedly), but when they die, any connections that they have opened will close (it might take a few minutes in the case of an unhandled exception, but they will eventually close).
As long as you keep the socket open, the server will be able to tell that the connection is still alive. No traffic need actually be passing between the two programs, but the server can tell all the same. And, when the socket is closed (because the other end has exited), the socket on the server will get the socket.on('end') event. At that point, the server can clean up resources, and its empty event loop will automatically shut it down.
I have a server where I handle multiple clients. Each client that connects to it is serviced in its own thread. Now, if any errors occur on the server side, I want to exit that thread by calling pthread_exit, and terminate the client that was being serviced by that thread. However; when I try to do so, my client is hanging. Also, this causes other clients that are in different threads to hang as well. I called pthread_exit in a random spot to test it...
Most likely the problem is that you are not calling close(newsockfd) before you call pthread_exit(). If so, then your server-thread goes away, but the socket that it was using to communicate with the client remains open, even though the server is no longer doing anything with it. Then the client's outgoing TCP buffer fills up, and the client waits indefinitely for the server to recv() more data from the socket, which never happens.
I have a NodeJS server set up that accepts TLS connections using the tls module: http://nodejs.org/api/tls.html
The clients are are using the NodeJS TLS module for the connections. I'm also storing a list/hashmap of all connected client and their IDs. If a client disconnects, then I will remove it from the list using the "error", "clientError" and "close" events.
This works in any normal case - however, when I "kill" the client (unplug power, unplug network cable) it seems like there is no event fired and the stream is open forever. Maybe I have overlooked something, but is there an event for something like this or how can I detect when the stream is not there any longer?
Sure, I could poll it in a certain interval, but that does not sound pretty good, since it will cause a lot of traffic (for almost no reason).
In the end, the stream is actually closed. If you try to call write, then it will cause an "write after end" error. Sadly, it seems like there is no event fired when the stream itself closes.
So right now, I'm just trying to write something every few minutes to see if the stream is still alive.