Libzmq: IPC not supported on windows

[msheridan]

I see you have a note that IPC is not supported on windows.

Looking further into this, I see in the library that there just isn't an implementation and the note claims that Windows doesn't support named pipes. That is just not true.

See: http://msdn.microsoft.com/en-us/library/aa365590(v=vs.85).aspx

Do you just need someone to create the implementation?

Cheers
Mike Sheridan
Westfork Consulting

[sustrik]

The problem win Win named pipes is that there are no associated file descriptors (sockets). Instead it's a HANDLE and thus it cannot be used with select().

To support named pipes new polling mechanism should be implemented (IOCP?) There have been some discussion about that on the mailing list, even some implementation attemps, but no working code so far.

[msheridan]

Isn't that what this example does (at least, essentially):

http://msdn.microsoft.com/en-us/library/aa365603(v=vs.85).aspx

Forgive me,for I haven't looked through much of the source for the library yet; is it that the design didn't put in an abstraction between itself and the underlying socket features, so all the code relies very closely on sockets and would be difficult to incorporate other underlying models (as would be needed here)?

[sustrik]

Yes, that's it.

The design is rather free. Currently we support select, poll, epoll, kqueue and dev/poll. So, if you feel like it, you can write IOCP polling mechanism and implement IPC transport on top of that.

[skrap]

Hey, I was curious about the final disposition of this bug. It's closed, but was the IOCP code written? Or was it found to be intractable? Or was this closed due to lack of interest?

[chuckremes]

It was likely closed due to lack of interest. You would have to search the mailing list archives for any word on any code that someone may have written. You could also try searching github for ‘IOCP zeromq’ or similar to see if any forks contain it.

It would still be quite nice to have this if only to provide better support and performance for our Windows brethren.

On Mar 25, 2014, at 2:37 PM, skrap [email protected] wrote:

Hey, I was curious about the final disposition of this bug. It's closed, but was the IOCP code written? Or was it found to be intractable? Or was this closed due to lack of interest?

—
Reply to this email directly or view it on GitHub.

[d-led]

There's new hope
https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/

[mannyk2]

I am very keen to use zeromq on Windows 10. What is the current status of this issue? Thanks.

[bluca]

You can use it with TCP

[denis-troller]

The problem with TCP is that if you plan on using a LOT of endpoints, it is much easier to programmatically build a pathname than agree on port numbers (and also you can run out of port numbers).
Windows DOES support AF_UNIX now so is there something preventing ZMQ fom using it ?

[bluca]

Windows DOES support AF_UNIX now so is there something preventing ZMQ fom using it ?

Only someone implementing it - pull requests are always welcome

[denis-troller]

Duly noted and deserved.

[EvanBalster]

Do I gather correctly that IPC has now been implemented on Windows?

See commit: https://github.com/zeromq/libzmq/commit/66d0f3511fe8b2e6393606990a3d66a846672f69

If so, that might be good to note here and in the guide. (http://api.zeromq.org/3-2:zmq-ipc)

[bluca]

Yes, it has been implemented

[EvanBalster]

Does the implementation rely on modern Windows features? I saw some things to suggest older Windows machines might need to fall back to something else.

[bluca]

It is only available on Windows versions that support AF_UNIX

[Nelson-numerical-software]

It is only available on Windows versions that support AF_UNIX

windows 10 (2004) libzmq 4.3.2 ?
zmq_strerror(zmq_errno()) returns:

Protocol not supported

so, supported or not supported ?

[mys007]

so, supported or not supported ?

It has been finally released in 4.3.3.

Though the implementation seems to silently ignore failures. Windows currently supports only pathname AF_UNIX sockets (https://github.com/microsoft/WSL/issues/4240) but ZMQ raises no error when binding or connecting e.g. to non-existent paths ("ipc://C:\\non_existent_dir\\my.socket") or abstract addresses ("ipc://@mysocket") but subsequent send/recv calls block.

[jpmn]

There's new hope
https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/

Check whether your Windows build has support for unix socket by running sc query afunix from a Windows admin command prompt.

[mannyk2]

Using WSL2 will work.

cheers

On Fri, Dec 11, 2020 at 7:29 AM Jean-Philippe Morin <
[email protected]> wrote:

There's new hope

https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/

Check whether your Windows build has support for unix socket by running sc
query afunix from a Windows admin command prompt.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/zeromq/libzmq/issues/153#issuecomment-743260918, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AI5OGHXYUXA2DR4UWMJZRKTSUI3HJANCNFSM4AIJS2TQ
.

--
When the power of love overcomes the love of power, the world will know
peace. Jimmi Hendrix

[Nelson-numerical-software]

Using WSL2 will work. cheers

Does it requires to install wsl2 or dependency is natively available without install wsl2 ?

It is an hard dependency :( not easy to manage with installer.