1)unix下面系統本身就是用管道（pipe）進行通信的，事實上就是比較簡單，而且比較簡單
2）socket會帶來一些額外的開銷，如網絡開銷，系統安全等等，不建議用，除非不是同一台機器
3）共享內存，控制起來麻煩，但是速度是會，帶來的麻煩就是程序要添加一些瑣或者是信號量，程序寫的不好容易出現死瑣現象
4）通過文件進行通信，不過這個速度是最慢的
2）socket會帶來一些額外的開銷，如網絡開銷，系統安全等等，不建議用，除非不是同一台機器
3）共享內存，控制起來麻煩，但是速度是會，帶來的麻煩就是程序要添加一些瑣或者是信號量，程序寫的不好容易出現死瑣現象
4）通過文件進行通信，不過這個速度是最慢的
5）消息隊列是消息的鏈接表，包括Posix消息隊列systemV消息隊列。有足夠權限的進程可以向隊列中添加消息，被賦予讀權限的進程則可以讀走隊列中的消息。消息隊列克服了信號承載信息量少，管道只能承載無格式字節流以及緩衝區大小受限等缺點。但開銷比較大。
Can anyone tell, how slow are the UNIX domain sockets, compared to Shared Memory (or the alternative memory-mapped file)?
Can anyone tell, how slow are the UNIX domain sockets, compared to Shared Memory (or the alternative memory-mapped file)?
It's more a question of design, than speed (Shared Memory is faster), domain sockets are definitively more UNIX-style, and do a lot less problems. In terms of choice know beforehand:
Domain Sockets advantages
Use memory instead of sockets in IPC ?
Do you know are there some reasons why many do not make processes to
communicate through memory? Why network connections (sockets) are used so commonly in IPC (inter process communication) instead of memory? (Is IPC harder to maintain / handle if it is made through memory, when compared to communication through sockets?)
Link
ANS 1
The basic answer is that IPC by means of reading/writing to
shared memory is too crude. At minimum you would need to
use a locking mechanism (semaphores, or similar) to make sure
your shared-memory operations are atomic and immune to events
such as interrupts. Sockets do all this for you.
A second, related answer is that writing to physical memory is less
safe. If a process accesses only its own virtual memory, it
cannot munge up other processes.
This is the whole idea behind having system calls, of which sockets
are one example -- so that each process does not have to write
into kernel memory and risk screwing up the entire system.
(Not that this isn't still possible through bad system calls, on most
systems.)
ANS 2
There are plenty of examples where shared memory is used. The support
for it is not as easy to find as reading and writing through
pipes/sockets so it tends to be used only where performance matters.
One of the biggest drawbacks is the "corruptability" of the memory. If
one process goes haywire, it can render the other processes reading the
shared memory also broken so the separation is somewhat important for
stability and security reasons.
If you take that into consideration, then it is understandable that
communication through a stream interface seems to be more prevalent.
Also, through magic of virtual memory, many pipe and socket
implementations "twiddle" the VM page tables which allow you to have
what is essentially a stream interface with most of the benefits of a
shared memory interface. Given this, it is even less of an imperative
for performance.
Another reason is that some architectures (PA Risc comes to mind) have
severe limitations on where files are mapped to memory.
Having said all this, there are ways of doing "shared memory" over a
network with support in the kernel to provide synchronization at the VM
level.
If time is critical, you should provide a shared memory interface. Many
of the issues I raised earlier can probably be "fixed" by writing some
code to deal with it. For example, the security issue can be solved by
providing private shared memory areas between two co-operating
processes. There is no way I know of doing that without the possibility
of having a third process possibly snoop in on the conversation but
there is no good reason why it could not be easily provided by the
operating systems. Process isolation can easily be done by having 2
shared memory areas, one for each communicating process that only that
process is able o write to, VM's provide this facility today. Finally,
the biggest language issue is you would like to share the objects in
memory if performance is a real issue. The problem here is that
addresses written to shared memory don't translate. It would be nice if
the C++ compiler provided a special "shared vtable" options to objects
with virtual methods, but alas, you would need to do that all by hand
which makes programming using shared objects alot harder.
Domain Sockets advantages
- blocking and non-blocking mode and switching between them
- you don't have to free them when tasks are completed
- must read and write in a linear fashion
- non-linear storage
- will never block
- multiple programs can access it
- need locking implementation
- need manual freeing, even if unused by any program
Use memory instead of sockets in IPC ?
Do you know are there some reasons why many do not make processes to
communicate through memory? Why network connections (sockets) are used so commonly in IPC (inter process communication) instead of memory? (Is IPC harder to maintain / handle if it is made through memory, when compared to communication through sockets?)
Link
ANS 1
The basic answer is that IPC by means of reading/writing to
shared memory is too crude. At minimum you would need to
use a locking mechanism (semaphores, or similar) to make sure
your shared-memory operations are atomic and immune to events
such as interrupts. Sockets do all this for you.
A second, related answer is that writing to physical memory is less
safe. If a process accesses only its own virtual memory, it
cannot munge up other processes.
This is the whole idea behind having system calls, of which sockets
are one example -- so that each process does not have to write
into kernel memory and risk screwing up the entire system.
(Not that this isn't still possible through bad system calls, on most
systems.)
ANS 2
There are plenty of examples where shared memory is used. The support
for it is not as easy to find as reading and writing through
pipes/sockets so it tends to be used only where performance matters.
One of the biggest drawbacks is the "corruptability" of the memory. If
one process goes haywire, it can render the other processes reading the
shared memory also broken so the separation is somewhat important for
stability and security reasons.
If you take that into consideration, then it is understandable that
communication through a stream interface seems to be more prevalent.
Also, through magic of virtual memory, many pipe and socket
implementations "twiddle" the VM page tables which allow you to have
what is essentially a stream interface with most of the benefits of a
shared memory interface. Given this, it is even less of an imperative
for performance.
Another reason is that some architectures (PA Risc comes to mind) have
severe limitations on where files are mapped to memory.
Having said all this, there are ways of doing "shared memory" over a
network with support in the kernel to provide synchronization at the VM
level.
If time is critical, you should provide a shared memory interface. Many
of the issues I raised earlier can probably be "fixed" by writing some
code to deal with it. For example, the security issue can be solved by
providing private shared memory areas between two co-operating
processes. There is no way I know of doing that without the possibility
of having a third process possibly snoop in on the conversation but
there is no good reason why it could not be easily provided by the
operating systems. Process isolation can easily be done by having 2
shared memory areas, one for each communicating process that only that
process is able o write to, VM's provide this facility today. Finally,
the biggest language issue is you would like to share the objects in
memory if performance is a real issue. The problem here is that
addresses written to shared memory don't translate. It would be nice if
the C++ compiler provided a special "shared vtable" options to objects
with virtual methods, but alas, you would need to do that all by hand
which makes programming using shared objects alot harder.
沒有留言:
張貼留言