Can not create NamedPipe on Windows

[forrestthewoods]

Describe the bug My attempt to make a DuplexMsgPipeStream is failing with "Error: The parameter is incorrect. (os error 87)". The failing call is to CreateNamedPipeW.

To Reproduce

    let listener = interprocess::os::windows::named_pipe::PipeListenerOptions::new()
        .name(OsStr::new("fts_pdbsrc"))
        .create::<DuplexMsgPipeStream>()?;

Expected behavior This trivial code should succeed.

Additional context It looks like there is a major refactor to Windows namedpipe. I grabbed master and successfully ran the tokio_named_pipe_server example. But the code has changed enough I'm not sure what is causing the difference.

[kotauskas]

Yeah, I've already changed a whole lot compared to the released 1.1.1 and there's still some work underway. The particular goal is to release 1.2.0 with Tokio support, replacing the existing generic async adapters, and to simultaneously release 2.0.0 with breaking changes towards the API of ancillary data on Unix-like platforms which are required to use said API on platforms with alignment checks, such as ARM and RISC-V. (1.2.0 will simply disable said functionality on non-x86 platforms by returning an unconditional error whenever the relevant APIs are called.) Note that I wouldn't actually consider this a security vulnerability, even though there is UB in that code, because on all supported platforms it's actually either defined to have a minor performance degradation, defined to return an error from the kernel (since the kernel is what's performing the unaligned memory accesses) or defined to crash the program in usermode. For practical purposes, this is a bug but not a security issue.

I did notice some bugs related to Windows named pipes during the refactoring and housekeeping associated with 1.2.0, and I do recall fixing them. You're right in saying that the major refactor makes those changes rather hard to spot, but reading through the commit history may reveal the exact bugs and fixes for them which I carried out. However, backporting those to the 1.1.x release line doesn't make any sense since by semver laws you can just upgrade from 1.0.x and 1.1.x to 1.2.x without any breaking changes.

I'll close the issue as soon as I release 1.2.0/2.0.0, which will have this fixed (even though the fix has already been implemented and is already in source control).

[forrestthewoods]

Thanks for the reply! Do you have a rough ETA on when you hope/plan to release 1.2.0/2.0.0?

I'm currently using std::net::tcp_listener / std::net::tcp_stream and they work fine. But firewall issues are a pain in the ass so I was going to attempt NamedPipe. At this point I'll probably stick with TCP and try NamedPipes again when you release this big update.

I might also do some profiling work. localhost is pretty optimized so I'm curious how NamedPipes perform vs TCP for certain types of workloads I regularly encounter. Which is usually some form of streaming sensor data. Payloads are small, 2-bytes to 64-bytes, and usually on the small side. But data rate can be high - 1000 Hz and up. Low latency is critical. Sounds like a good blog post. :)

[SonicZentropy]

Is it safe to use the current repo version over 1.1.1 now? I'm running into this pretty hard and there's not much indication of a 1.2 release anytime soon, so I'm not sure whether to trudge onward or wait. Thanks for the great crate!

[kotauskas]

Yeah, the master branch, at this moment (5a16b3a), successfully builds on Windows and already has all the patches for named pipes that I intended to release as version 1.2.0. For the time being, you can pull in the version with this code in Cargo.toml:

[patch.crates-io]
interprocess = { git = "https://github.com/kotauskas/interprocess", rev = "5a16b3a" }

Leave out the rev parameter for packages which provide executable crates (have main.rs or [[bin]]), since the Cargo.lock is typically checked into version control for those.

For the time being, 1.2.0 is stalled by async Tokio support. I'm already done with the code for Unix domain sockets (it's not checked in yet), and the Windows Tokio named pipe code is already in version control. The only things left to do now are the local socket interface for cross-platform Tokio-powered IPC, finishing up the examples and documentation adjustments, and some minor cleanup and testing.

I'll try to hurry up and push what I already have, but if you just want the non-async (or legacy async) IPC, the configuration above can give you the 1.1.1 functionality with 1.2.0 patches before I actually release the update to Crates.io.

[SonicZentropy]

That's perfect, thanks so much!

[kotauskas]

1.2.0 is finally out, so I'm closing this one! No need for that patch thing anymore, interprocess = "1.2.0" will pull in the new version with the bugfixes directly from Crates.io.