🚀 go-pugleaf

In <4b872c9b.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes:

>> 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 :-)

(I'm amused by the reason :-). It may be helpful, though, to consider a real,
live RFC--comments you get from a Request for Comments may give you some hints
on how to make NCS work efficiently on the Internet. 

One thing I found ambiguous in the Architecture book was the use of Fragment
Acknowledgment. Page 30 of the Architecure book says that the fragment
acknowledgment may be set in a packet to request acknowledgments of the
individual fragments. However, I found no mention of how a programmer would
require or prohibit fragment acknowledgment. Under what conditions would
someone want fragment acknowledgment? Why is this something an applications
developer should worry about?

On page 43, the "Suggested Time" for fragment acknowledgment is 1 second (it's
my understanding that all of these timers are hardwired in a given NCS
implementation). Isn't a 1-second timeout far too short for fragment
acknowledgment? If the mean round-trip time for 2 Internet hosts is 5 seconds,
won't this mean that fragments will get needless multiple retransmissions?

>> 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.

I'm talking about NCS's connection-oriented protocol on top of UDP. If you
truly think that you've invented a better mousetrap, these are the folks that
I'll believe.

Speaking of TCP/IP, from an earlier posting:

|> A couple of general questions:
|> 
|> 1. Why is NCS2.0 being offered on top of connection-oriented transports?
|>    Under what conditions will you recommend that programmers specify using
|>    connection-oriented transports?

> Some environments have only COTPs.  (E.g., our ISO/OSI friends have not
> yet seen the wisdom of making a priority defining and implementing CLTPs.)
> We want NCS to run in these environments.  Hence we must make NCS run
> over COTPs.

It is true that some environments only have COTPs. However, I have never seen
a TCP/IP environment that did not have access to UDP/IP and vice versa. (Does
anyone know of any exceptions?) Why bother putting NCS2.0 on top of TCP/IP? If
you do provide NCS on top of TCP/IP, when do you recommend that it be used?

>> 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.

Either multi-threading is a keystone of NCS, or it isn't. If multithreading
isn't available in all environments, then your proposed mechanism of doing 
asynchronrous RPC via forking a thread won't work.

> 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.)

How portable is it? How does the availability of NCS compare with RPCGEN? How
about Netwise's RPC Tool? How big is the NCS compared with these other
products?

> 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.)

I believe you mean that NCS provides no control of the granularity. One can
control the range of a broadcast by changing the address mask.

>> 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?

If you're doing asynchronous calls, you have some point when you have enough
information to perform the call, but don't need the result immediately. A
simple strategy is to go back to what you're doing until you need the results,
then block waiting for them.

If you don't understand that, then I don't understand what you meant in an
earlier posting:

> My religion says that they're a bad idea because they're hard to understand,
> represent an unnecessary new aspect in the computing model, and that one
> should use existing primitives for asynchrony (process) and communications
> (procedure call) together to achieve the same effect.

Do you mean that a process should fork a new thread to do the RPC call? In
your example, isn't the parent thread going to do stuff for "a while" then
"check for a result" of its child? Sounds at least as hard to me.

For other readers: it's useful to remember one other thing about async
operations. Async is pretty simple to understand if there is only one
outstanding operation.  It is possible to have multiple async calls over a
connection, but the rules get much more complicated. I would not recommend
multiple outstanding asynchronous calls over the same connection.

> 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)?

Yeah, it looks like multi-threaded systems will become more widespread. It
will be interesting to see what sort of problems that this unleashes on the
world. I'm not tremendously enthusiastic about locking out all other threads
every time I want to modify a global. The one that really frightens me,
though, is the process of software maintenance. Some junior programmer will
not understand THE RULES for changing a multi-threaded application and will
introduce bugs that will not surface for months later....

I had claimed that there was no automatic system for detection of data access
collisions; this was incorrect. It turns out that the Space Shuttle computers
are multiprocessing but not memory-mapped--different processes are accessing
the same global data. Unfortunately, the computers provided facilities for
protecting only 256 variables; a typical shuttle mission has over 9,000 shared
variables. The computer designers came up with a novel solution: since are
points of synchronization between the processes, the relative time that each
process is accessing each variable is known. From this data, the designers
were able to create an "alabi file" for each variable that exhaustively
examined each access and *proved* that no reads and writes overlapped.
Needless to say, computation of these proofs take a rather astonishing number
of computrons and had a rather negative impact on code flexibility in the
shuttle.

Phil Earnhardt          Netwise, Inc.  2477 55th St.  Boulder, CO 80301
Phone:303-442-8280      UUCP: onecom!wldrdg!pae
My opinions do not reflect any official position of Netwise.