Anonymous user
Message Passing: Difference between revisions
m
Reverted edits by Melina148 (talk) to last revision by Khaledhammouda
| [unchecked revision] | [unchecked revision] |
m (Fixed typo) |
m (Reverted edits by Melina148 (talk) to last revision by Khaledhammouda) |
||
| (11 intermediate revisions by 5 users not shown) | |||
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.
==Reliable vs Best-Effort==
;reliable
: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
: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 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
:Process A delivers the message directly to process B. If process B is not ready to receive at the moment of sending, Process A is suspended and queued upon Process B's 'sending' queue, until Process B is receiving. Using this method, you don't need to care for message queues - but you enqueue processes. Note that if process B is waiting to receive a message from process A, and the message fails to be delivered (due to an error, or some failure in the message delivery system, for example) then process B will block indefinitely.
;asynchronous
:Process A sends the message to Process B. The message is copied to a dedicated region in kernel space and attached to Process B's message queue (lets call it the Post box). The next time, Process B looks into its postbox, it will retrieve the message. You can have processes block for receiving a message or just stroll by and check whether there is something to fetch. One could call this method "store and forward message passing". The main benefit of asynchronous messaging is that it allows a single thread/process to wait for the results of many unrelated "requests" at the same time. However, any erroneous (or malicious) process can repeatedly spam messages in quick succession to other processes, thus tying up system resources in a denial-of-service attack.
We may note that in the synchronous approach, A has the guarantee that B received the message when the deliver call terminates, which makes it especially interesting for local RPC. It should be noted that it can be very difficult to implement standard C library functions without this guarantee.
Line 17 ⟶ 26:
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.
==The "Port" abstraction==
Line 24 ⟶ 35:
To solve situations when a server is willing to receive messages from different ports (and synchronous messaging is used), we need a select-like interface that will allow reception of a message from any port p in a given set of ports.
==Mailboxes==
There may be some cases in which a thread will want to broadcast the same message to multiple threads at once, or perhaps a set of producer threads has to communicate with another set of consumer threads. In such cases, mailboxes can queue messages for multiple receivers. Mailboxes are similar to ports, except multiple recipients may retrieve messages instead of just one. A mailbox is not owned by a single thread, but is a common resource provided by the OS that's shared among the receiving threads. The order in which messages are received may either be ''first-in-first-out'' (FIFO) or based on message priority.
==Variable or Fixed Messages Size==
Line 30 ⟶ 44:
When messages longer than the fixed-size are required, one will need to provide a way to describe the long message in the small structure. If copying a 4-word message forth and back doesn't imply excessive processing cost, it will be very different for the 1MB of data you send to a disk server. In that case, it is suggested to toy with paging in order to map the real data from the emitter to the receiver's address space.
== See Also ==
=== Articles ===
* [[Remote_Procedure_Call|Remote Procedure Call (RPC)]]
* [[Message Passing Tutorial]]
* [[IPC Data Copying methods]]
=== Threads ===
Line 37 ⟶ 55:
*[[Topic:10922|RPC message size, handling oversized messages]]
=== External Links ===
*[[Wikipedia:Message Passing | Message Passing]] on Wikipedia
*[[Wikipedia:Message queue | Message Queue]] on Wikipedia
[[Category:IPC]]
[[Category:OS theory]]
| |||