I have a question. I think that pipes are unidirectional and the other IPC facilities exist that can be used for bidirectional, like shared memory or POSIX message queues. I encountered error when used two pipes for bidirectional when buffers were longer, as it was ready for fd & read & write that was from another thing. I think that pipe is a FIFO, but I want to know how different they are implemented and how can it be better to use? If the mistake of me was it.

I've been writing C on various platforms for many years. While that does not make me either an expert or all-knowing, I am not aware of any full duplex IPC* implementations. Remember that "full duplex" means that both ends of the connection are writing at the same time. Think of your data as a ping-pong ball and your IPC as a tube. If both ends insert a ball at the exact same instant, nothing appears at the other end. Any library that claims to be full duplex likely have two connections under the bonnet.

Two processes may open the same file as read-write. The application must have some protocol so that both process avoid trying to manipulate the same data at the same time. This protocol often involves record-level locking or some other mutex*.

Every time I have read or written code using pipes or fifos* or sockets, there has been a pair of connections -- read this one and write that one.

_________________
* IPC -- [i]nter-[p]rocess [c]ommunication
mutex -- [mut]ual [ex]clusion algorithm
FIFO -- [f]irst [i]n [f]irst [o]ut

1 members found this post helpful.

If you have a single CPU/core system, simultaneous writing is physically impossible - the CPU is shared by the OS between the applications, so in any case just one application writes (and reads for that matter) at a time.

Still, the two applications may have two buffers in shared memory:

application1 writes to buffer1, application2 reads from buffer1;
application2 writes to buffer2, application1 reads from buffer2.

For that matter, the buffers may be not only explicit buffers in shared memory, but also named pipes:

man 3 mkfifo
man 1 mkfifo
.

OP: I don't really understand what your question is, but (like most political commentators) that won't stop me adding my thoughts on this subject:

For me, TCP is basically always my preferred method of IPC. One program listens to connections on localhost, another connects as a client - full-duplex communications between two programs, easy. Plus, it makes it a trivial matter to extend either program to talk to a remote machine, even if they're running different operating systems or are a completely different architecture. You can even make it secure between two physically separate machines using tunnelling, and that can all be implemented from outside your program.

About the only thing this is unsuitable for is passing data at high speed (e.g. real-time audio) - even then, I'd almost always use TCP to pass information about shared memory segments (e.g. the key to use to access the shared memory) and to notify programs of updates to shared memory.

Just my two pence (I'm British).