Network-like IPC (IPC is interprocess communication)

Something like network datagrams (UDP), but all on one system,
and a fixed size datagram for simplicity.

Idea of a service: a certain port handles a certain service.
A client of the service sends a datagram to that port with
needed input data for the service, and a datagram comes
back with the answer or result. See examples below.

Idea of server: A server "listens" to a port for a certain
service by doing dgram_receive in a loop. When a datagram
comes in, it is from a client asking for the service.
The server does the indicated work and replies back to
the client with the answer or result.

Suggested new system calls:

#define DGRAM_LEN 100

int dgram_send(int dst_port,short src_port,char *data)
Send DGRAM_LEN bytes of data to spec. dst_port 
identified as coming from src_port on this system.
Like a return address on a letter, the src_port provides a well-
defined way for the other end to reply to this message.
Blocks as necessary to do its job, but does not return definite 
success or failure indication--it just does "best effort" to get the
data to its destination.  Failure return means early failure,
success return only means initial success. 

int dgram_receive(short dst_port,short *src_port,char *data)
Block if necessary to receive a datagram for the spec. port.
User provides data buffer of DGRAM_LEN bytes for
the data, just as in the read syscall.  No guarantee on data
integrity, but normally should be OK.  

Implementation

The recipient of a datagram may be busy with something else
when the datagram comes in. So datagrams need to be queued up.

Consider Xinu ports for useful places to queue up frames.

Test Applications--do at least two of these, or propose your own.
Write appropriate user-level programs for testing.

Console Output Service

Let's designate port 100 for this important service.  A server process
listens on port 100 for any datagrams and interprets them as follows:
First 2 bytes give length of message to print, in 2 ASCII digits,
"00" up to "98", then the message follows--this fits in the 100 bytes
of the datagram.  Any process on the system can send such a datagram
to port 100 and get it printed.

Name Service

On port 200, a server daemon holds a table of string names up to
20 chars long, and associated int values.  Processes can add a
name-value pair (or "association" as the AI people like to call it)
with an add-name formatted datagram, or read the current value for
a name with an get-name datagram.  You design the formats.

Lock Service

On port 2000, an applications-level lock server takes in lock and
unlock datagram requests, sends datagram replies delayed as needed
to block the lock attempts on locked locks.  Implement at least
one lock, preferably more.

Note: You may notice that the server is not always in a dgram_receive,
so the kernel has to accept a datagram that has no apparent
receiver, hoping that a server will do a dgram_receive.  In the
real Linux UDP service, a server has to get a "socket" object from
the kernel using the "socket" system call and bind a port number
to it with the "bind" system call, before doing the loop of 
system call recvfrom's using that socket as an argument. 
Thus the kernel has a longer-term knowledge of the server ports
and can reject datagrams for ports that have no binding. Also, 
a second bind on the same port fails, so the kernel enforces the 
rule of no more than one server for each port. If you would like 
to add sockets to your Xinu service, that's great.