NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/protocol/misc/649

Internet Message Format | 1992-09-03 | 3.7 KB

Path: sparky!uunet!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!pepper.Eng.Sun.COM!cmcmanis
From: [e-mail] (Chuck McManis)
Newsgroups: comp.protocols.misc
Subject: Re: compare socket based and RPC based...
Date: 4 Sep 1992 08:20:07 GMT
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 63
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: pepper

In article <[e-mail]> [e-mail] writes:
>Hi Net Gurus,
>could any one tell me the advantages of "Socket Based interprocess
>communication" over "Remote Procedure Call based interprocess communication"?

General question, deserves a general answer. The short answer is that
they are the same thing, only the specification of the protocol is
different. Andrew Birrell et al in a paper in the Feb '84 ACM Transactions
on Computing Systems noted that by using a request/response protocol
and a procedure call model you could accomplish a lot of useful work
over a network. As you know a procedure call, as compiled by a high
level language, generally has a prologue which places parameters to
be used by the procedure into some common area, then transfers control
to the procedure, then fetches the results of the common area and
continues executing. Generalized to networks you marshall up all of
your parameters, then send them over the wire to another thread of
execution which uses them in some computation, and then it returns
results to you and you pull them off the wire and use them.

So what a good (for some definition of good) RPC system does for you
is allows you to specify what is going to come over the wire, where
it is going to go, and what sort of results you expect to get back.
Other things it can do for you are to transmit the data in an architecture
independent format so that you can communicate to systems which have
different architectures without worrying about what byte order that
system uses or what floating point format it requires. It can also
provide a buffer between you and different network "stacks" or transports
to make porting your code easier.

>My questions are:
>1.why and when the socket based communication is used?

Well if you absolutely must have the highest possible performance and
are willing to pay the maintence burden of rewriting your code for different
networks, then sockets are for you. Its analagous to programming in
assembler.

>2.Why always RPC based communication is prefered over socket based
>communication is prefered?

They aren't always. Some things you might want to do with the network
don't really map well into a procedure call model. An example of this
is doing "one to many" communication where a single "call" from your
application results in several network messages being generated to
several servers. The ISIS system is a good example of some of the things
you can do using a network that certainly don't make sense on a uniproccessor
system, and probably not on an MP system either. (They do loosely coupled
operations spanning multiple systems)

>3. Is it possible to implement a 'Client-Server' model using  sockets? if yes,
>can i call 'My-application-program=X.25-switch' (as given in steps 1-4) as
>a 'cleint=server' model?

Of course it is. Get a copy of the source to Sun's RPC library from rice.edu
or an archive server near you and take a peek. Its whole purpose in life is
to make writing and maintaining network applications easier. Your application
in particular sounds like a good fit for this kind of technology.

--
--Chuck McManis                            Sun Microsystems
uucp: {anywhere}!sun!cmcmanis   BIX: <none>   Internet: [e-mail]
These opinions are my own and no one elses, but you knew that didn't you.
"I tell you this parrot is bleeding deceased!"