6 ms·

I don't think it's difficult to design an IPC mechanism. But I DO think it's difficult to design an IPC mechanism that everyone is happy with. Some people want

I don't think it's difficult to design an IPC mechanism. But I DO think it's difficult to design an IPC mechanism that everyone is happy with. Some people want only synchronous IPC, others also asynchronous (out of order responses), some want multicast, some want events without associated request, some want pub/sub, etc. If at the end people continue building their own IPC mechanisms on top of TCP/IP or unix domain sockets then the in-kernel mechanism will just be another thing to maintain. There had been some endaveurs to bring new IPC mechanisms into the Linux Kernel (AF_BUS, KDBUS, BUS1). I think those failed for similar reasons (although I'm not sure were BUS1 now is - the others are definitely discontinued).

jacquesm 7y ago
KISS: QnX MsgSend, MsgReceive, MsgReply. That's really all it takes. http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc.neutrino_lib_ref%2Fm%2Fmsgsend.html http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2F... You can go all the way from the lowest level kernel uses to very high level application constructs with that. Re-inventing existing wheels badly is something the software world excels at.
- als0 7y ago
  > That’s really all it takes. Not quite. Those functions need established connections, so you need ConnectAttach and ConnectDetach as well. But none of that is useful unless you can identify clients so you also need ConnectClientInfo. This isn’t a dig, having worked on a custom IPC system I found the QNX approach to be the best of all worlds.
  - jacquesm 7y ago
    Sure, but the essence of the actual transfer, the part where performance matters is send/receive/reply.
zzzcpan 7y ago
> But I DO think it's difficult to design an IPC mechanism that everyone is happy with. Some people want only synchronous IPC ... Every form of IPC can be implemented on top of asynchronous message passing. Interface is not the problem. The problem is high performance designs with all the batching, memory mapped buffers, no syscalls, etc.
- naasking 7y ago
  > Every form of IPC can be implemented on top of asynchronous message passing Sure, if you want to introduce inherent DoS vulnerabilities into your IPC subsystem, not to mention slow down IPC so much that it's practically unusable. Many early microkernels were asynchronous, and synchronous microkernels like L4 beat them easily every time. Furthermore, synchronous IPC can be made immune to DoS which is inherent to async IPC: https://www.researchgate.net/publication/4015956_Vulnerabilities_in_synchronous_IPC_designs https://www.researchgate.net/publication/4015956_Vulnerabili...
  - zzzcpan 7y ago
    > Sure, if you want to introduce inherent DoS vulnerabilities into your IPC subsystem, not to mention slow down IPC so much that it's practically unusable. This is nonsense. There could be DoS vulnerabilities in implementations, but they are not inherent to async message passing.
    - naasking 7y ago
      Yes they are. Who owns the buffers needed to store the async messages? 1. If they're booked to the receiver, then clients can easily DoS receivers by flooding them with message. 2. If they're booked to the sender, then receivers can easily DoS senders by blocking indefinitely. 3. If they're booked to the kernel (which is most common for true async message passing, unfortunately), then senders or receivers can DoS the whole system by the above two mechanisms. And that's only the most basic analysis. I suggest you read the paper I linked and its references if you want a more in-depth analysis of IPC vulnerabilities and performance properties.

jacquesm 7y ago

KISS: QnX MsgSend, MsgReceive, MsgReply. That's really all it takes. http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc.neutrino_lib_ref%2Fm%2Fmsgsend.html http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2F... You can go all the way from the lowest level kernel uses to very high level application constructs with that. Re-inventing existing wheels badly is something the software world excels at.

als0 7y ago
> That’s really all it takes. Not quite. Those functions need established connections, so you need ConnectAttach and ConnectDetach as well. But none of that is useful unless you can identify clients so you also need ConnectClientInfo. This isn’t a dig, having worked on a custom IPC system I found the QNX approach to be the best of all worlds.
- jacquesm 7y ago
  Sure, but the essence of the actual transfer, the part where performance matters is send/receive/reply.

zzzcpan 7y ago

> But I DO think it's difficult to design an IPC mechanism that everyone is happy with. Some people want only synchronous IPC ... Every form of IPC can be implemented on top of asynchronous message passing. Interface is not the problem. The problem is high performance designs with all the batching, memory mapped buffers, no syscalls, etc.

naasking 7y ago
> Every form of IPC can be implemented on top of asynchronous message passing Sure, if you want to introduce inherent DoS vulnerabilities into your IPC subsystem, not to mention slow down IPC so much that it's practically unusable. Many early microkernels were asynchronous, and synchronous microkernels like L4 beat them easily every time. Furthermore, synchronous IPC can be made immune to DoS which is inherent to async IPC: https://www.researchgate.net/publication/4015956_Vulnerabilities_in_synchronous_IPC_designs https://www.researchgate.net/publication/4015956_Vulnerabili...
- zzzcpan 7y ago
  > Sure, if you want to introduce inherent DoS vulnerabilities into your IPC subsystem, not to mention slow down IPC so much that it's practically unusable. This is nonsense. There could be DoS vulnerabilities in implementations, but they are not inherent to async message passing.
  - naasking 7y ago
    Yes they are. Who owns the buffers needed to store the async messages? 1. If they're booked to the receiver, then clients can easily DoS receivers by flooding them with message. 2. If they're booked to the sender, then receivers can easily DoS senders by blocking indefinitely. 3. If they're booked to the kernel (which is most common for true async message passing, unfortunately), then senders or receivers can DoS the whole system by the above two mechanisms. And that's only the most basic analysis. I suggest you read the paper I linked and its references if you want a more in-depth analysis of IPC vulnerabilities and performance properties.