Sysvad design decision

I’m following this article to create a noise cancelling app: Help with design decision (using sysvad virtual driver as base) — OSR

But there is a difference that instead of using ioctl to communicate between user-mode and kernel-mode, I’m using named pipe. Everything seem to be working fine so I wonder if named pipe has any limitation or disadvantage comparing to ioctl?

Thank you.

Named Pipe vs IOCTL

Well, these are very different mechanisms. An IOCTL will be far less overhead. A named pipe can be opened remotely. It is rather unusual to use a named pipe to communicate to a driver that’s local to the requestor. But… if it works… that’s not something to so quickly dismiss.

Peter

1 Like

I think that the performance of a local named pipe IO won’t be much different than a double buffered IOCTL - but the CreateFile part will be much different as it opens the handle on both ends. also knowing which side operates as the ‘server’ end of the pipe and knowing when that is available from the ‘client’ end of the pipe are clear issues that have well defined solutions with standard IOCTLs. Be aware that using a named pipe creates a potential security vulnerability because the network redirector will expose this end point over the network. Without an appropriate security descriptor, that may allow a remote system to either block real data (i.e. calls fail with ERROR_PIPE_BUSY) or to inject synthetic possibly malicious data. The default configuration of windows firewall mitigates this to a large extent for non-AD joined machines, but many features of windows require RPC enabled

noise cancelation is not something that should generally be performed on a system that is remote from the one actually playing the audio i would think

1 Like