At times, emacs buffer talks to an external http (or) epc server and sends out queries. To do that, it establishes a network connection with it, which remains open until the query's response is written to process buffer. What command lists out the open connections between emacs & external server?
Related
There is a long connected TCP socket. Up to two clients can connect to a server. In other words, the load is not high. However, once a TCP connection is made, the socket will not be disconnected unless there is an accident, such as a server power down or network failure. Is it possible to reuse an existing TCP socket when restarting the process? I think TCP load balancer like AWS NLB cannot be used since the existing socket won't be moved to a new application. I'd like to have a deployment without downtime, as the system i'm working on is a system that can suffer financial damage when a socket is broken and data is lost. Low-level socket programming is ok.
I have read CloudFlare's https://blog.cloudflare.com/graceful-upgrades-in-go/ article explaining Nginx's Gracefully Reload mechanism. Since an HTTP server is a server that opens and closes sockets frequently, that article assumes that the server's connection would someday be closed, but my situation is slightly different. So I'm not sure if this can be used.
A socket can be shared between multiple processes, for example by opening the socket in same parent processing and forking a child process. But if the last process using the socket is closed the socket and thus the underlying connection is implicitly closed.
This means you must make sure that there is always a process open which uses the socket. This can be for example done if the deployment of the new software does not first exit the old process and then creates the new one but if the new process would start and the old process would transfer the socket to the new one, see Can I share a file descriptor to another process on linux or are they local to the process?
for how this can be done in Linux. Other ways would be using file descriptor inheritance when doing a fork().
Note that these sharing of file descriptors will only work with plain sockets where the state is fully kept in the OS kernel. It will be much harder or impossible with TLS sockets since in this case also the current user space state somehow needs to be shared.
Another way is to have some intermediate "proxy" which on the hand has the stable socket connection to your fragil application and on the other hand is a robust socket handling (i.e. reconnect when needed) to the application you want to update. Then this proxy transfers the traffic between both sides and will reconnect the socket if needed whenever a problem occurs.
This (rather old) article seems to suggest that two Unicorn master processes
can bind to the same Unix socket path:
When the old master receives the QUIT, it starts gracefully shutting down its workers. Once
all the workers have finished serving requests, it dies. We now have a fresh version of our
app, fully loaded and ready to receive requests, without any downtime: the old and new workers
all share the Unix Domain Socket so nginx doesn’t have to even care about the transition.
Reading around, I don't understand how this is possible. From what I understand, to truly have zero
downtime you have to use SO_REUSEPORT to let the old and new servers temporarily be bound to the
same socket. But SO_REUSEPORT is not supported on Unix sockets.
(I tested this by binding to a Unix socket path that is already in use by another server, and I got
an EADDRINUSE.)
So how can the configuration that the article describes be achieved?
Nginx forwards HTTP requests to a Unix socket.
Normally a single Unicorn server accepts requests on this socket and handles them (fair enough).
During redeployment, a new Unicorn server begins to accept requests on this socket and handles them, while the old server is still running (how?)
My best guess is that the second server calls unlink on the socket file immediately before calling bind with the same socket file, so in fact there is a small window where no process is bound to the socket and a connection would be refused.
Interestingly, if I bind to a socket file and then immediately delete the file, the next connection to the socket actually gets accepted. The second and subsequent connections are refused with ENOENT as expected. So maybe the kernel covers for you somewhat while one process is taking control of a socket that was is bound by another process. (This is on Linux BTW.)
Suppose we have two process having the same port, but one at a time one will be using it and other one will be in passive mode and once the active process goes down, the passive will start reading from the port.
now since in linux everything is a file descriptor, i wanted to know is there any way where passive process can immediately start reading from the port.
Currently i am closing the port in active process and then again open it in the passive once it becomes active.
Thanks in advance.
No, only one process can read from a port at a time. Even on linux, when a process uses the port, it locks it. It is linux architecture that everything is a file(with exception of network devices). But these device files(or ports) are special files or device files. You cannot manipulate them as normal files.
My goal is to remotely write code. So far, I have been using ssh + screen + an editor (e.g. vim).
I understand using a local emacs (or vim), one can edit remote files. But once the local emacs is closed and I want to reopen it (or open it using another computer), I would need to reopen all the buffers again.
Is there a way to set up a emacs server on the remote machine and I could simply access it using a local emacs client? Which essentially simulate the screen behavior.
I think you might find your answer here;
http://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html
According to http://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Options.html#emacsclient-Options ;
An Emacs server usually uses an operating system feature called a “local socket” to listen for connections. Some operating systems, such as Microsoft Windows, do not support local sockets; in that case, Emacs uses TCP instead. When you start the Emacs server, Emacs creates a server file containing some TCP information that emacsclient needs for making the connection. By default, the server file is in ~/.emacs.d/server/. On Microsoft Windows, if emacsclient does not find the server file there, it looks in the .emacs.d/server/ subdirectory of the directory pointed to by the APPDATA environment variable. You can tell emacsclient to use a specific server file with the ‘-f’ or ‘--server-file’ option, or by setting the EMACS_SERVER_FILE environment variable.
Even if local sockets are available, you can tell Emacs to use TCP by setting the variable server-use-tcp to t. One advantage of TCP is that the server can accept connections from remote machines. For this to work, you must (i) set the variable server-host to the hostname or IP address of the machine on which the Emacs server runs, and (ii) provide emacsclient with the server file. (One convenient way to do the latter is to put the server file on a networked file system such as NFS.)
When the Emacs server is using TCP, the variable server-port determines the port number to listen on; the default value, nil, means to choose a random port when the server starts.
Of course, make sure to adjust your firewall settings on the server side, so that clients may connect to the machine running the emacs-server.
I've attempted the method mentioned in the other post many times and have never had any success with it.
One nice thing that emacs is able to do is desktop-save-mode which will store all of your open buffers when you kill emacs and restore them when you open emacs again. By default it won't restore tramp buffers, but you can tweak the settings to allow this to happen. More information can be found in this Stack Overflow question.
You can login locally and then ssh to a remote machine. On the remote machine, you can have 'screen session, that you can join'. In this session, you have emacs running, with all buffers as you had left. You can also use the desktop-save in combination to this, in the case that remote machine need to be restarted, and you can lose your session. This is the most practical solution, I use. You can change the 'client computer' any time. You don't need to use local emacs client. You can also make multiple session for different projects and join screen session for a particular project on different terminal.
I have a simple node.js client and server programs running on one machine and when I try to connect to the server with second instance of client program simultaneously I get EADDRINUSE, Address already in use error. Is it possible to have two or more TCP based socket client connections (created with createConnection) to one server (created with createServer) on the same machine, or only one client program can be connected to the server at the same time?
Yes, it's possible. Infact, very common. Many applications open dozens, or hundreds of connections to the same server. It sounds like your client program is binding on a port. Only the server should be binding on a port. You should verify.
The client will usually use a random port between 1024-65535, as assigned by your OS. You don't need to worry about it. Since the client is initiating a connection to the server, the server port must unique to one program. Which is why your problem signifies you are trying to start the server twice. Please see http://www.tcpipguide.com/free/t_TCPIPClientEphemeralPortsandClientServerApplicatio.htm