nng_dial for sub0 called synchronously is returning before the socket is ready to receive messages about nng HOT 6 CLOSED

FYI I have just had the problem occur with nng_msleep(1) as well, so evidently this isn't quite enough to work-around this problem.

from nng.

Yeah, I'd guess msleep 10 would be better. :-)

Due to the way Windows IPC works, there are some asynchronicity things going on under the hood that make it hard to be fully synchronous. TCP (and IPC on UNIX systems) doesn't suffer this.

I'll look again to see if there are things I can do to make this better. The entire IPC mechanism for Windows is a strange beast, as it is entirely unlike UNIX domain sockets.

from nng.

dial also always runs more or less asynchronously, even on TCP and UNIX sockets -- because of the way NNG is architected. There isn't really a great solution to this, as at present there is no two-way handshake. We could add a complete two way handshake, but that would make the setup take a little longer, and it would break compatibility (which is the real reason we haven't done it yet).

from nng.

It is perhaps an unusual situation where it is desirable to have complete synchronization for the dial operation, however, if it's possible to implement a complete two way handshake perhaps we could avoid breaking compatibility by only doing this if a different flag is passed to the dial function?

from nng.

The problem is that any way you do it, you have to implement changes to the wire protocol.

I want to fix this someday, but it requires a protocol update. Not going to happen this week. :-). And probably not the next either. :-)

It is possible to implement this synchronization in your application protocol btw. I just can't do it at the NNG / SP protocol without breaking compatibility for other SP applications.

from nng.

I'm going to close this for now. It's not something I'm going to do until I refactor the entire wire protocol.

from nng.