0

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!

YasserKaddour
  • 880
  • 11
  • 23
Northstar11
  • 21
  • 1
  • 7

1 Answers1

0

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.

saghul
  • 1,990
  • 1
  • 13
  • 15