🚀 go-pugleaf

In <1990Jul10.224543.20314@athena.mit.edu> pae@athena.mit.edu (Philip Earnhardt) writes:
>Actually, things should work pretty smoothly under TCP. Since the connection
>is being maintained by the kernel, the acknowledgment can be sent immediately
>after the packet is processed by the kernel. NCS would have the ack sent out 3
>seconds after the user process has processed the data. Also, acknowledgments
>can be sent back to the server for fragments of the message.

I suspect things WON'T work smoothly under TCP, for the reasons I said.
First, your scenario (100 different clients each make a single non-idem
call to a server) implies that the server is able to open (and keep open
without being considered anti-social) 100 TCP connections.  (BTW, whether
your system lets you have more than 32 file descriptors is only the first
issue.  How many simultaneous TCP connections your kernel allows and
how much these "cost" in kernel resources are others.)

Second, with TCP, any data sent on a connection that is not yet ack'd
is consuming wired kernel buffers.  There is nothing that REQUIRES a
receiving TCP to acknowledge a TCP segment immediately upon its receipt.
TCP implementations should (lord knows if most do) have the goal of
piggy-backing ack's on data flow in the reverse direction to avoid the
sending of gratuitous empty TCP segments (IP packets) that simply contain
ack info.  

In any case, TCP having the "connection maintained by the kernel" really has
pretty little to do with anything.  NCS could ack every response packet
immediately after it arrived (as opposed to postponing the way it actually
does).  The delay induced by switching out from the kernel to user mode
upon packet receipt isn't the problem.  The problem is that the sender
is stuck with whatever ack policy the receiver is following.  Sure, you
can solve the sender's problem by ack'ing all the time.  However, if you
know the sender has a moderate to large amount of buffering capabilities
(because the buffers are page-able and in user space), you can ack
at a more reasonable rate and save network bandwidth.

>It's probably not necessary to understand all the nuances of the NCS
>implementation in order to understand the fundamental problem with a
>connection-oriented protocol implemented outside the kernel on top of a
>datagram transport.

There is certainly some reason to be concerned that it might be the case
that the kernels we have around don't provide enough information in
a timely fashion to user mode to make the implementing of a connection
oriented protocol (like NCS over UDP is) as good as one would like.
Our (and other's) experience has shown that one can live with the limitations.
(And as you can see from my earlier comments, the alternate approach of using 
TCP is not without limitations either.)

>If the connection-oriented scheme at the user level were the way to go, why
>isn't everyone else jumping on the bandwagon? 

Beats me.  OSF seems interested.

>Why not implement X that way?

Ask the X folks.  Presumably they decided that they were more interested in
doing window system stuff than network protocols.

>Are there any RFCs that discuss the NCS technology? 

At the time we set out to write the NCA book, we considered whether it
could/should be an RFC.  For better or worse, the book was written with
a WYSIWIG editor and (at least until recently) RFC's had to be in flat
ASCII form.  Apparently Postscript RFCs are now accepted.  We could produce
the book in Postscript and submit it as an RFC.  Somehow I think it's
probably simply for people who are interested to just get the book.
(The royalties to HP are nothing to write home about, I assure you :-)

>Have any of the Internet gurus endorsed it?

As I understand it, the topic of RPC is one that surfaces regularly at
some IETF working group meetings.  I don't think they've endorsed anything
at this time.

>
>> Everything is a matter of degree.  Broadcast is a feature that a relatively
>> few (and hopefully almost no) applications need.
>                     ^^^^^^^^^
>??? In order for your GLB to work, you need broadcast.

OK, substitute "close to one" for "almost no".  The idea is that most
applications will leverage off of a single broadcast (to the GLB) so
that those applications themselves don't have to use broadcast for anything
else.  Also, the GLB can be be accessed without broadcast (i.e., via
specifying its location in a local config file).

>> See "Network Computing Architecture" (Prentice-Hall, ISBN 0-13-611674-4).
>> Let me know if it doesn't answer all your questions.  We tried to be
>> complete, but I wouldn't be surprised if we failed in some areas.  There's
>> always the next edition :-)
>
>I had already looked through this book. I hadn't found answers to the
>specific questions I had asked:
>
>   o What type of packets NCS is sending (UDP or IP).

UDP.  I had intended there to be an appendix to the book titled
"NCA/RPC in the IP environment".  It fell through the cracks.  The
mapping is straigtforward.  One NCA/RPC datagram is one UDP packet.

>   o When acknowledgments are sent. (there's some information about the timers,
>     but there's no timeline charts about what goes down the wire.)

Sounds like a good area for improvement.  Presumably you understand the
picture based on my postings.

>   o How retransmission timers work--when are they used, what values are
>     they set to, how the application can change the values.

Actually, I thought this was covered, but perhaps not clearly enough.

>For these systems, there will have to be modifications to the OS to support
>multiple threads (I assume non-preemptive application-provided multithreading
>won't work). There's the added expense of a new OS and the hassles of
>configuring/installing the system software.

Well it's a surprise to me that the OS needs to be modified.  A number
of people have written useful multi-threading packages that don't require
OS mods.  Presumably some OS's would require mods.  Presumably some OS's
don't have C compilers either.  My goal is not for me to fix every
problem in the world.

>Some of these computer systems may be at the end of their product cycle; the
>manufacturer may be unwilling to make any changes to their OS. There may be
>architectural reasons that mutlithreading can not be implemented in some
>environments. Should Distributed Computing not be available in these
>environments just because NCS implementations require multiple threads?

Clearly someone should figure out how to build implementations that don't
require multiple threads.  Like I said, my goals is not for me to fix
every problem in the world.  The portability of a single implementation
of a system is only one measure of a system's usefulness.  NCS is highly
portable.  No, it is not infinitely portable.  Sue me.  (Be prepared
to sue lots of people who produce lots of software that lots of people
use and consider to be portable.)

>The response didn't seem to address the issue raised. How exactly does one
>specify the granularity of the broadcast?

Sorry.  I didn't understand this to be your question.  There is no control
over the granularity (by which I assume you mean "scope").  This is one
of the reasons people dislike broadcast.  (Some people, including me,
like MULTIcast, but unfortunately, access to such facilities is pretty
hit-or-miss these days.)

>The comparison between (preemptive) multiple threads and asynchronous calls is
>interesting.  I find asynchronous calls fairly straightforward--you place the
>call, do something else for a while, check for a result, and get the reply. 

Another religious issue for sure.  My problem is that I don't know what
"a while" and "check for a result" mean:  when and how do I do it?
Multi-threading systems will be implemented and become widespread.  Such
systems have primitives for doing synchronization (signalling and waiting
for events).  Why do you want to invent and make me use duplicate primitves
(in support of async RPC)?

                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com