NaemdPipe on dust layer

[givesun]

Dear All,
I'm interested in iceoryx_dust layer.

Seeing the following page, There is a NamedPipe.
https://github.com/eclipse-iceoryx/iceoryx/tree/master/iceoryx_dust

I'm little bit confused about the description of NamedPipe.
-> NamedPipe | Shared memory based IPC channel. Mainly a UnixDomainSocket replacement on Windows.

I have few qustions.

1. Is this using shared memory? or using posix named pipe itself?
2. Is this support zero-copy like hoofs's roudi?
3. Could you please explain the replacement of UnixDomainSocket in more detail?
4. I'm using the namedpipe in linux, Is there a merit to use NamedPipe of Dust?

[elfenpiff]

@givesun

Is this using shared memory? or using posix named pipe itself?

It is based on shared memory and a lock-free queue.

this support zero-copy like hoofs's roudi?

Zero-copy is usually a combination of a communication channel which transmits only pointers to the data and a shared memory which contains the data. The NamedPipe is one possible communication channel to transmit pointers, in combination with a shared memory object containing the data one can establish zero-copy communication.
This is for instance done in Windows.

Btw. roudi is our central broker which establishes the connections and manages the resources and is not located in hoofs

Could you please explain the replacement of UnixDomainSocket in more detail?

We have multiple IpcChannels to establish rudimentary communication between processes. By default we use an ipc channel based on unix domain sockets, this is not available in windows and therefore we implemented the NamedPipe as alternative IpcChannel.

I'm using the namedpipe in linux, Is there a merit to use NamedPipe of Dust?

In theory a named pipe should be faster since it does not interact with OS mechanisms like the ones required for a socket based communication.
You can take a look at the iceperf example: https://github.com/eclipse-iceoryx/iceoryx/tree/master/iceoryx_examples/iceperf
Here we compare different mechanisms with iceoryx.

Since we are using the unix domain socket based IpcChannel only in the startup process the iceoryx communication can be very well compared to a pure namedpipe communication since they are both based on shared memory and the same queues.

[givesun]

Thanks for kind explanation.
Could you please check the followings? Is my understanding correct?

1. NamedPipe in dust is designed for Window OS because Windows doesn't support unix domain socket.
2. NamedPipe which is in dust is zero-copy. By using shared memory and lock free queue, NamedPipe is satisfying zero-copy.
   -> Regarding this, I have a question. The named pipe in linux(posix) is not zero-copy ipc as I know.
   Because There is a copy between user-space and kernel. And There is context switching.
   I think NamedPipe in dust is zero-copy. If this is right, I think Namedpiped in dust will provide better performance
   comparing linux named pipe. Am I right?
3. The NamedPipe in dust is named 'NamedPipe', But I think there is no any relation with linux named pipe.
   Before I understood The NamedPipe is some kind of wrapper to wrap linux pipe, But I think it's not. Right?

[elfenpiff]

@givesun

1. Correct.
2. One can define zero copy as: Multiple processes share memory and the communicate pointer to data to this shared memory instead of the data directly. The NamedPipe in Linux is identical to the NamedPipe in Windows. We cannot draw the conclusion that the NamedPipe in Windows, Linux, MacOs or any other OS is faster or slower since the implementation is always the same and the performance depends solely on the OS. So one requires a benchmark.
   Context-switching and copy between user-space and kernel refers to a comparison to unix domain sockets. Unix domain sockets imply, caused by the OS specific implementation, a context switch. The copy depends on the OS specific implementation for them. But they can be used also for zero copy.
   The key to zero copy is that only pointers to data are transmitted instead of the data itself.
3. Correct. Here we maybe used the wrong name for the construct. We should refer to it in the future as iceoryx named pipe to distinguish it from other constructs like a named pipe in linux.

[givesun]

@elfenpiff
Thanks for your help, I could understand more about iceoryx, Thank you very much.

Could you please teach me the followings? I have few questions about the current implementation of zero-copy in iceoryx.

1. Posh layer, This is the zero-copy ipc and It accomplished zero-copy by using shared memory & semaphore(Or using signal directly?).
   If there are additional things(ex: sendto, splice, vmsplice...) to do zero-copy, Please teach me.

2. I saw the following layer and I found there is a unix_domain_socket.hpp.
   (https://github.com/eclipse-iceoryx/iceoryx/tree/master/iceoryx_hoofs/include/iceoryx_hoofs/internal/posix_wrapper)
   Is this some kind of supporting layer? as you mentioned on your first comment
   ("We have multiple IpcChannels to establish rudimentary communication between processes")
   I think this is not zero-copy. As I know, To do zero-copy in socket, We need to use sendfile(). (If my knowledge is not correct Please tell me)
   So, My question is like the follwings.
   The unix_domain_socket is just some kind of supporting thing to provide additional ipc mechanism
   Or Do you have a plan to support this as a zero-copy ipc in the future?