libuv-如何测试侦听套接字与客户端（中继应用程序）的断开连接

Question

My application sporadically modifies and relays messages that it receives to a listener server daemon (all using unix domain sockets, so uv_pipe_t).

1. (Workflow that has me stumped) When the first message has to be relayed, it makes a uv_try_write() in the uv_read_done callback function (where it is reading on a listening socket of its own)

   • If the listening daemon is already up and running, this is the perfect, and the message is relayed
   • If the listening daemon is not yet up
     • uv_try_write fails, I check the status which is -ve (EAGAIN), so I try a connect (uv_pipe_connect). After this I uv_try_write() again.
     • Since the connect fails (ENOENT, I log an error and give up.)
   • I now start the listening daemon up
     • The uv_try_write again fails on the first message, despite the connect() (because I presume it makes the connect in the next loop iteration)
     • The second write onwards works fine and as expected
   • I kill the listening daemon
     • On the coming write, the app receives a SIGPIPE error ( I have blocked this with sigaction and sigprocmask)
   • I restart the listening daemon
     • This time the connect() fails with an EISCONN error ( which I presume means that the handle I used in the first connect is still live, and needs to be closed. However, since I cannot detect when the connection was closed from the listener daemon the last time, I cannot know when to close the handle.

2. Questions about best practice

   • Is the the best way to design the relay app? Perhaps not, because it is not very resilient dropping messages on reconnections, and I do not want to make hacks around this without ensuring I am following the proper practices using libuv
   • If it is, are any of the following options worthy?
     • some periodic timer setup heartbeating with the peers
     • a uv_check handle that is checking for connection status at every loop iteration somehow. If so, how to check for connection status? uv_is_writeable always returns 0, even on a connected socket. Same with uv_is_active
     • uv_try_write() from the on_connect callback function to send the first message that is getting dropped

Thanks very much in advance for the help!

Answer 1

You can call uv_write after you call uv_pipe_connect , and the write will be queued. Writes will happen after the connection succeeds, or fail with UV_ECANCELED if the connection failed.