🚀 go-pugleaf

In article <1992Oct13.172450.29593@magnus.acs.ohio-state.edu> dlray@magnus.acs.ohio-state.edu (Donald L Ray) writes:
>Its my understanding that RPC -remote procedure calls- provides the
>mechanisms through a local procedure that may be executed remotely on a
>remote processor and results returned to the local procedure. How new
>is this?


This is an old idea.  I've seen it in use in for over a decade.  I'm sure
it showed up even earlier than that.

It has a good point and a bad point.

The good point is that it's easy to program -- nothing new -- just the same
old procedure calls.

The bad point is that while the callee is doing its thing *and* while that
call is being transmitted *and* while the reply is coming back, the caller
is twiddling its thumbs -- either literally spinning or doing a task
switch.  As processors get faster, the time for the callee to do its thing
goes down -- but the communication time doesn't (since the speed of light
doesn't change).  So the number of instructions wasted in the caller goes
up, if the caller spins.  This forces the caller to task-switch or waste
time.


So -- you get a *big*, distributed system with lots of shared resources but
it runs like a PC Jr. (OK, so I exaggerate :-).

In article <7201@transfer.stratus.com>, cme@ellisun.sw.stratus.com (Carl Ellison) writes:
|> The bad point is that while the callee is doing its thing *and* while that
|> call is being transmitted *and* while the reply is coming back, the caller
|> is twiddling its thumbs -- either literally spinning or doing a task
|> switch.  As processors get faster, the time for the callee to do its thing
|> goes down -- but the communication time doesn't (since the speed of light
|> doesn't change).  So the number of instructions wasted in the caller goes
|> up, if the caller spins.  This forces the caller to task-switch or waste
|> time.


RPC's can be both synchronous and asynchronous, If you can use asynchronous RPC's,
then the initiating process can go on processing. And in todays world, a machine
that is waiting on an RPC for one process will probably go out an work on another
process, which tends to keep the overal user response time faster, since some of
the work is being done somewhere else.

And in response to the original poster...rpc's _have_ been around for a while. 
If you have ever used NFS, you have used RPC's, since this is how NFS obtains
files from the NFS server.


-- 
Jon Alperin - Bellcore
---> Internet: jona@iscp.bellcore.com
---> Voicenet: (908) 699-8674

* All opinions and stupid questions are my own *

"I don't have any experience running up a 4 trillion dollar debt" - Ross Perot
"If there's a fair way, I'm all ears" - Ross Perot

In article <7201@transfer.stratus.com> cme@ellisun.sw.stratus.com (Carl Ellison) writes:
>...
>The good point is that it's easy to program -- nothing new -- just the same
>old procedure calls.

This is mostly true.  The network interface can add complications in
the form of exceptions which would not be their in the straightup
procedure call environment.

>The bad point is that while the callee is doing its thing *and* while that
>call is being transmitted *and* while the reply is coming back, the caller
>is twiddling its thumbs -- either literally spinning or doing a task
>switch. 

I'm not sure how ONC handles this but in DCE threads are used so that
the entire process need not block.  When you use threads with rpcs you
effectively blur the line between client and server at the process
level.  For example, in our first DCE based application each user
interface process was both a client of the database server and a
server itself which exported an interface used for asynchronous
message passing between users.  It's possible for one of these
processes to be issuing calls to the database server while servcing
it's own interface simultaneously.


Best regards,
-- 
Kevin P. Tyson		Phone:  212-657-5928	Fax:    212-657-4599
E-Mail: Kevin_Tyson@fig.citib.com or kpt@iisa.com

In article <7201@transfer.stratus.com>, cme@ellisun.sw.stratus.com (Carl Ellison) writes:
|> The bad point is that while the callee is doing its thing *and* while that
|> call is being transmitted *and* while the reply is coming back, the caller
|> is twiddling its thumbs -- either literally spinning or doing a task
|> switch.  As processors get faster, the time for the callee to do its thing
|> goes down -- but the communication time doesn't (since the speed of light
|> doesn't change).  So the number of instructions wasted in the caller goes
|> up, if the caller spins.  This forces the caller to task-switch or waste
|> time.

Let me disagree. Don't forget that the speed of light is not the only source of
network communications bottleneck. In my understanding, a very little portion
of latency is due to the light speed limit. On a local network with a physical
range of say 10 miles, the light would make a roundtrip in about 0.1 msec 
(10 * 2 / 186000 ) wich is quite acceptable. 

The real delays which are in the range of 5-100 msec come
in my understanding from routers, gateways, packet switcher, network overload, ...

If I remember correctly, the theoretical speed limit of a network packet 
is something around 0.8 * c (eighty percent speed of light).

So, as processors become faster, so do the routers and gateways. We are also going
to have networks with much higher capasity which will increase the size of
packets and reduce the number of packets required.

It is my understanding that in the nearest future (10-15 years) the processors 
(and not the networks) will be the bottleneck in the RPC or any client-server
scenario.

-- 
Alex Berlin                     
berlin@is.morgan.com