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

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.