socket.close() is not really synchronous but there is no event to notify when it is really closed

[pghalliday]

I'm having problems writing tests for my service due to not knowing when a socket has really been closed and thus the port can be reused (so that I can bring up new instances over and over again in my tests)

The following coffeescript/mocha test illustrates the problem

  describe 'When re-using ports', ->
    it 'should be able to bind to a new 0MQ socket immediately after closing an old one', (done) ->
      socket1 = zmq.socket 'pub'
      socket1.setsockopt 'linger', 0
      socket1.bind 'tcp://*:8000', (error) =>
        expect(error).to.not.be.ok
        socket1.close()
        socket2 = zmq.socket 'pub'
        socket2.setsockopt 'linger', 0
        socket2.bind 'tcp://*:8000', (error) =>
          expect(error).to.not.be.ok
          socket2.close()
          done()

which results in the following error

Fatal error: expected [Error: Address already in use] to be falsy

I can workaround it with a timeout (which is a bit arbitrary as slower machines may take longer, plus it will slow my tests down if they all contain timeouts) or by cycling through ports, which is likely to be a pain to manage unless I write a library to manage it (which seems like overkill)

Ideally I would like an event once the socket has really been closed so that I can design my tests to run fast and look sensible.

Apologies if I missed something in the API

[kkoopa]

This might not be all that easy, at least not with TCP sockets. I don't know if zmq's linger option sets the SO_LINGER option on the underlying tcp socket, it would seem reasonable for it to do so, but I am not sure. Anyway, as you might know, with TCP sockets, calling close only closes the connection to the socket, not the actual socket. By default, the socket then enters the TIME_WAIT state to wait for pending packets between 1 to 4 minutes, depending on implementation, after which the socket finally is closed. Using an ipc socket, this would not occur, as they don't have delivery guarantees.

Assuming that zmq's linger option does set SO_LINGER on a tcp socket, it is zmq that needs to support noticing this before this binding can implement it. I don't know if the OS sends notifications on socket state changes either, if there is no such functionality, it will require polling.

TLDR:
This won't work with TCP sockets, because they have delivery guarantees. It is possible that an ipc socket will work in the desired fashion. If you still want to use TCP, then capture the EADDRINUSE error and cycle the port or wait and poll until it is closed.

[JamesMGreene]

I believe you should be using unbind instead of close since you previously bound the socket.

describe 'When re-using ports', ->
  it 'should be able to bind to a new 0MQ socket immediately after closing an old one', (done) ->
    socket1 = zmq.socket 'pub'
    socket1.setsockopt 'linger', 0
    socket1.bind 'tcp://*:8000', (error) =>
      expect(error).to.not.be.ok
      socket1.unbind 'tcp://*:8000', (error) =>
        expect(error).to.not.be.ok
        socket1.close()
        socket2 = zmq.socket 'pub'
        socket2.setsockopt 'linger', 0
        socket2.bind 'tcp://*:8000', (error) =>
          expect(error).to.not.be.ok
          socket2.unbind 'tcp://*:8000', (error) =>
            expect(error).to.not.be.ok
            socket2.close()
            done()

[pghalliday]

Thanks, I may resurrect my project to test this :)

[JamesMGreene]

I feel your pain, though... this project is not very well documented. I usually end up looking at their unit tests to get a better idea of how to do what I'm interested in.

[JamesMGreene]

FWIW, this is probably the most relevant unit test file for your situation:
https://github.com/JustinTulloss/zeromq.node/blob/master/test/socket.unbind.js

[pghalliday]

Thanks dude :D

[reqshark]

If something obvious is missing from docs, please PR to fix

[ronkorving]

There's a PR coming that documents node-zmq better, along with updates to the API: #516
In the mean time, of course PRs are welcome to fix node-zmq as it is today.