SIMPL open source project... / Send/Receive/Reply message passing

[Christopher Browne]

On 6/28/06, Jason Spiro <jasonspiro4-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> On 6/22/06, bob <ican-rZHaEmXdJNJWk0Htik3J/w at public.gmane.org> wrote:
> >
> > In reality the SIMPL API is really just 5 main functions:
> >
> > name_attach() - to register a process name
> > name_locate() - to open a communication channel to a process found by
> > name
> > Send() - throw off a message and wait for a response
> > Reply() - respond to a message
> > Receive() - wait for a message to be thrown your way
>
> Isn't this similar to the use of TCP sockets or Unix named sockets?

Sure, it's *similar*.

But that's only true in the bland sense that "everything on Unix
involves manipulating files."  Which may at some level be true, but if
you're trying to reverse engineer someone's binary data format, it may
include a whole lot of cursing...

By layering the API on top, you don't need, as a programmer, to pay
attention to the details of how messages go back and forth.  It's easy
to work with messages; they look nice and atomic, as opposed to
figuring out how many bytes to read from a socket.

The docs for Isect outline this nicely...
http://isectd.sourceforge.net/isect_1.html#SEC1

---------------------------------------------
Long before the buzzwords "client-server" and "middleware" were ever
coined, programmers used middleware to build client-server systems.
They programmed using character or block IO directly to the network
devices which may have been proprietary, like Data General's MCA
cards, or standard like UARTs for serial communications.

Over TCP/IP networks, regardless whether the network interface is
token-ring, ethernet, or PPP, the socket library developed at the
University of Berkeley became the standard way for programs running on
different computers (or even the same computer) to communicate with
each other.

But writing servers is more complicated than just read()ing requests
from a client. What if there are multiple clients? What if the client
dies while you're still processing? What if the server dies? How does
the client find the server? Should or must the server be multitasking?
How should semaphores be used? These issues all concern network
programming and have little (read: nothing) to do with what the
programmer really needs the server to do. In fact, for simple server
programs the overhead of the network programming may make it not worth
it to create the server in the first place.
---------------------------------------------
-- 
http://www3.sympatico.ca/cbbrowne/linux.html
Oddly enough, this is completely standard behaviour for shells. This
is a roundabout way of saying `don't use combined chains of `&&'s and
`||'s unless you think Gödel's theorem is for sissies'.
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml