Message Passing: Difference between revisions

Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
m (→‎See Also: Something went wrong)
(Changed Unreliable to Best-Effort)
Line 1: Line 1:
If you consider writing a [[Microkernel]], you should layout how you'll manage the message passing. This page collects considerations on how you can do it.
If you consider writing a [[Microkernel]], you should layout how you'll manage the message passing. This page collects considerations on how you can do it.


==Reliable vs Unreliable Messaging==
==Reliable vs Best-Effort==
;reliable
;reliable
:Messages are always delivered unless the recipient does not exist. On failure, the sender is notified. In order to provide reliability, the message passing system ensures that messages have not been altered or corrupted between transmission and reception. Out-of-order message blocks are reordered and duplicate message blocks are removed. If an error occurs, the system will attempt to retransmit the message automatically. Reliable messaging, however, usually comes with noticeable overhead.
:Messages are guaranteed to be delivered unless the recipient does not exist. On failure, the sender is notified. In order to provide reliability, the message passing system ensures that messages have not been altered or corrupted during transmission and reception. Out-of-order message blocks are reordered and duplicate message blocks are removed. If an error occurs, the system will attempt to retransmit the message automatically. A message's transmission time will tend to be predictable. Reliable delivery of messages, however, usually comes with noticeable overhead.


;best-effort
;unreliable
:Messages may/may not be delivered to the recipient. If a message ''is'' delivered, its contents may be corrupted, out of order, or duplicated. Also, the sender may not receive any acknowledgment of a successful delivery. This may sound entirely useless, but unreliable messaging is typically simpler and faster than reliable messaging. By putting a reliable message protocol on top of unreliable messaging, reliable messaging can be achieved (very much like the TCP protocol[reliable] with IP packets[unreliable]). Such a protocol might utilize "ACK" messages and timeouts to support reliable messages.
:Messages may/may not be delivered to the recipient. If a message ''is'' delivered, it may be after a variable delay. Messages could be corrupted, out of order, or duplicated. Also, the sender might not receive any acknowledgment of a successful delivery. This may sound entirely useless, but best-effort delivery is typically simpler to implement than reliable delivery and comes with lower overhead. By implementing a reliable messaging protocol on top of a best-effort delivery protocol, reliable delivery of messages can be achieved (very much like the TCP protocol[reliable] with IP packets[best-effort]). Such a protocol might utilize "ACK" messages and timeouts to support reliable messages.


Reliable messaging is used when data ''must'' be delivered correctly bit-by-bit (as in transferring a file). Unreliable messaging is used when data must be sent quickly or when it doesn't really matter if some messages are corrupted or lost (like periodic "I'm alive" messages or when streaming audio/video).
Reliable delivery is used when data ''must'' be delivered correctly bit-by-bit (as in transferring a file). Best-effort delivery is used when lots of data must be sent with low processing overhead or when it doesn't really matter if a few messages are corrupted or lost (like periodic "I'm alive" messages or when streaming audio/video).


==Synchronous vs Asynchronous==
==Synchronous vs Asynchronous==
Line 27: Line 27:
What primitives will you need to get both asynchronous and synchronous message passing running? Three: send(message), receive(message) and request(message), as the send(message) primitive is/can be the same as the respond(message) primitive.
What primitives will you need to get both asynchronous and synchronous message passing running? Three: send(message), receive(message) and request(message), as the send(message) primitive is/can be the same as the respond(message) primitive.


It is possible to get synchronous message passing via asynchronous message passing primitives and vice-versa. Message forwarders along with acknowledgment messages and messaging protocols can make this possible. Unfortunately, doing it this way is not efficient.
It is possible to get synchronous message passing via asynchronous message passing primitives and vice-versa. Message forwarders along with acknowledgment messages and messaging protocols can make this possible. Unfortunately, doing it this way is not efficient.


==The "Port" abstraction==
==The "Port" abstraction==