Wednesday, September 29, 1993
-------------------------------------------------------------------------------
Announcement:  No class on Friday
-------------------------------------------------------------------------------
Today: Interprocessor communication (communication with messages)
	Send/receive based
	Remote Procedure Call (RPC) based
-------------------------------------------------------------------------------
Previously have discussed *shared memory* systems
Now, processes that have independent state.  Communication via *messages*
Messages: pieces of information that are passed from one process to another
Message operations (first definition)
	send(P, message): send a message to process P
	receive(Q, message): receive a message from process Q
Specific implementations of send and receive depend on system
	(discussion later)
-------------------------------------------------------------------------------
Example using producer/consumer

producer				consumer
while(true) {				while(true)  {
	produce data in nextp
	send(consumer, nextp);			receive(producer, nextc);
						consume data from nextc
}					}
-------------------------------------------------------------------------------
Why use messages?
- model is sequential flow of information; many applications fit this
model naturally
- processes are totally separate (except for message)
	- less error prone implementation; no invisible side effects;
	  processes cannot gain access to each other's memory (also
	  security benefit)
	- appropriate in cases where processes cannot trust each other
	  (i.e., OS and user processes)
	- permits separate development---different times by different
	  programmers---as well-defined interface can be enforced
	- permits distribution, even across different kinds of
	  processors on a network
Some issues
	- does the sender block until receiver acknowledges message?
	  if not, does the link have a capacity---i.e., how much
	  buffer space before error or blocking required?
	  (synchronous versus asynchronous)
	- does receive block until message arrives or just return "no
	  message" to receiver?  (synchronous versus asynchronous)
	- does sender have to specify exactly one receiver or can one
	  in a group receive messages?  (direct communication vs
	  indirect communication)
	- does receiver have to specify sender or can it accept
	  messages from different senders?  (direct communication vs
	  indirect communication)
-------------------------------------------------------------------------------
Terminology for indirect communication:
messages sent to and received from mailboxes (alternatively called
ports).  Processes communicate by sharing a mailbox.  Messages
deposited into mailboxes and extracted from mailboxes.
	send(A, message): deposit message into mailbox A
	receive(A, message): extract message from mailbox A
-------------------------------------------------------------------------------
Implementation questions:
	- can a process "own" more than one mailbox?  Simplest to
	implement if only one process but not as flexible
	- if a process owns more than one mailbox, can it *wait*
	on more than one mailbox at a time?
	- if nonblocking send/receive possible, how much buffering?
	More efficient for large transfers when sender and receiver
	run at varying speeds)
	- zero capacity---sender must wait for receiver to avoid
	message loss: synchronization called *rendezvous*
	- alternative: zero capacity buffer without blocking requires
	synchronization to avoid losing unreceived message
-------------------------------------------------------------------------------
rendezvous:
	send(Q, message);			receive(P, message);
	receive(Q, message);			send(P, "ack");
-------------------------------------------------------------------------------
	- what gets passed in messages?  Fixed size or variable size?
	structured (records) or unstructured (stream of bytes)?
	- what happens when a process terminates?  receiver may block
	forever unless system notifies receiver that sender has
	terminated (or terminates the receiver).  implication:
	messages passed by OS here.  If above OS can't notify
	- does it matter if messages are lost?  some protocols
	guarantee reliability, others don't (e.g., for time-critical
	events).
	- reliable transmission alternatives
		- OS detects lost message (e.g., using
		  timeout or sequence count) and resends
		- Sending process detects lost message (e.g., using
		  timeout) and resends if desired
		- OK detects lost message and notifies sender which
		  takes action as it desires (resends or not)
	- messages may also arrive out of order
	- messages may also be internally scrambled by network
	- ISO OSI reference model addresses some of these.  Different
	  layers provide successively greater erro detection and
	  correction (perhaps more at some later date)
-------------------------------------------------------------------------------
Remote Procedure Calls (RPCs)
High-level concept for process communication
Programmer-view is same effect as regular procedure calls
Each RPC is pair of synchronous send and receive statements.
	send transmits input parameters
	receive acquires corresponding results
Remote procedure
	begins with a receive (to acquire actual parameters)	
	terminates with a send (to provide results)
Sun RPC encapsulates these into an event-driven structure
Remote procedures implemented as a set of "handlers"
Invoking remote procedure causes handler to be invoked (atomic).
Results from handler returned to caller (e.g., result of manipulating
	some data structure)
-------------------------------------------------------------------------------
Next: Chapter 6