How does pingora implement zero downtime reload?

[myyrakle]

As far as I know, proxy systems such as nginx/HAProxy implement zero-downtime reload by separating processes on a master-worker basis.

On the other hand, according to the document, Pingora seemed to implement zero-downtime by somewhat directly controlling the file descriptior.

From what I understand, zero downtime replace is handled in the following flow.

What I'm curious about here is how the listener replacement was achieved with zero downtime.

Even if I stop listening on the old server and immediately start listening on the new server, isn't it possible for a very small "hangup" to occur?

I'm curious about the details of pingora's implementation of this.

[myyrakle]

I read the documentation and code again and wrote down what I understood.

A. before reload

B. after run new server. new server share port (using IP_BIND_ADDRESS_NO_PORT?)

C. When the old server receives sigquit, it enters graceful shutdown mode.

• Requests previously received by the old server are processed directly (until graceful timeout)
• From now on, requests received by the old server will be forwarded to the new server through the upgrade socket (I am not sure)
  
  

D. The old server is terminated, and only the new server runs.

Is my understanding correct?

[myyrakle]

Ah... I think I understand after looking at the code.

The old server blocks I/O, writes the socket connection information to the upgrade.sock file, and the new server receives it, creates a socket, and executes it.

During the process, the client is blocked from receiving I/O, but the connection is not lost, and when the new server is executed, the request is processed.

Is that right?