🚀 go-pugleaf

In <1990Jul20.032431.7497@athena.mit.edu> Jake Edge (onecom!wldrdg!jake), 
appearing this night only as pae@athena.mit.edu (Philip Earnhardt) writes:

>In <4b8742f6.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin)
>writes:
>As you have stated, threads will provide a way to do asynchronous RPC
>(for environments that support threads), but you also seem to believe
>that asynchronous RPC is blasphemous (i.e. your religion says that it
>is a bad thing). You really can't have it both ways. And though threads
>will provide a method to accomplish async, it is clearly a much less
>straightforward mechanism for an application programmer to use. This
>is one of the reasons that I believe customization is by and large a
> good thing.

I'm not sure what you think the contradiction is.  Asynchrony is a fact
of the world.  I'm neither for nor against it.  I merely want to take
advantage of it with a single, extant abstraction:  the process model
("threads").  You appear to think abstraction is not straightforward
and invent another one:  asynchronous procedure call.  You're entitled.
I'll stick with the existing orthogonal abstractions of process and
procedure call.

>The Netwise tool does not inflict its users with the biases of the tool
>designers.

I'm happy to let the market judge my biases. 

>So, to paraphrase, the authentication and privacy features of NCS 2.0
>are hardcoded. They could be changed by you folks if Kerberos doesn't
>make it as a standard, but application developers (i.e. customers who
>buy NCS) are stuck with it. I would not try to claim that there is
>something inherently wrong with Kerberos, but if some developer has
>a legitimate problem with it (perhaps because it uses the DES), and
>they are working under NCS 2.0, they are stuck ... true? I suppose if
>an NCS user really had to change it for their own reasons, they could
>buy the NCS source and replace the Kerberos module...

At worst.  If the demand appeared to exist, I suppose we could document
the interface between the authentication module and the rest of NCS.
This would allow people to write authentication modules without having
the source to NCS.

>In addition, I think it would be more fair to say that modularizing
>the Kerberos portion of NCS is a standard engineering decision.

Ah, we agree on at least one thing!

>>I don't know about your "two camp" notion.  If two camps are present
>>anywhere, it's at the network layer:  some people think it's important
>>to have CL network protocols (like IP) and some people don't think it's
>>so important (and are happy to have [only] a CO network protocol).  No
>>one disagrees about the need for CO transport protocols.
>
>Am I missing something here? Isn't UDP a CL transport protocol that is used
>by a fair number of current applications (including NFS which is likely the
>most widely used RPC application in the world today)? 

I guess I'm not sure what point you're trying to make.  You initially
made some comments about there being two "camps" and that our choice of
uniform RPC behavior over various transports put us in the CO "camp". 
The only "camp" we're in is the one that thinks that the behavior of a
remote call should be constant.

>Aren't there provisions for a CLTP in the OSI reference model?

Provisions:  yes.  Widespread implementations:  unclear.

>I think that there are those who would disagree about _only_ having
>a COTP (which may be stretching your statement a bit).

I said:  "No one disagrees about the need for CO transport protocols." 
Maybe that was an obscure phrasing.  I think everyone thinks we should
have COTPs.  I didn't say "everyone thinks we should have ONLY COTPs".

>But again, you folks are constraining the choices of your customers. 

As does the C compiler writer who chooses to make his compiler save
registers on ALL procedure calls, not just on those generated by a
compiler targeted for a particular hardware architecture.

>There are distinct sets of advantages and disadvantages to CO vs. CL
>transports and the NCS product allows only the set for CO transports.

What are you talking about?  Stop talking about transports.  Talk about
RPC.  Sun RPC has the "advantage" that it allows you to make procedure
calls whose semantics are ill-defined (or defined to be something like
"at LEAST once") and, as a result, optimizations can be made to reduce
the cost of doing the RPC.  It turns out that this "advantage" is selected
by telling the programmer which transport to choose.  In NCS, we achieve
the analogous optimization by telling people to declare a procedure to
be "idempotent".  Idempotence is a property of a procedure, not a network
transport protocol.  Since we're dealing in remote PROCEDURE calls, this
seems like the more appropriate abstraction.

>BTW, if the home-brew CO transport over UDP is so much better than TCP,
>why didn't you folks stay with that for NCS 2.0 rather than adding TCP
>support?

One reason NCS 2.0 runs over TCP because TCP is about the only practical,
widespread COTP around and we want to demonstrate that NCS can run over
COTPs.  Also, it is not inconceivable that TCP will behave better than
NCS's own protocol in certain environments.  People in such environments
may choose to use NCS/TCP.  We want to give our customers a choice too,
you know :-)

>With the Netwise approach, you get (in effect) _both_ CL and CO RPC
>and allow user of the tool to decide for themselves which of these two
>options is 'best' for their application. If a user wishes the advantages
>of a CL RPC (largely reduced overhead) and is willing to pay the price
>that implies (lost messages, etc.), they should have the opportunity
>to make that decision. Clearly there exist applications that will benefit
>from this.

We've been over this again and again.  People don't want "CL and CO RPC".
They want RPC.  They want to make certain performance tradeoffs made
available to them.  NCS addresses this desire in an appropriate way.

---------------------

In <1990Jul20.033536.7794@athena.mit.edu> pae@athena.mit.edu (Philip Earnhardt)
writes:
>Since you provided no details about how this modularization works, it's
>difficult to comment. Presumably you provide a mechanism for the
>application to specify the security routine(s).

We believe the authentication modularization has sufficient generality.

>Actually, the "two camp" notion comes from ISO. In case you are unfamiliar
>with ISO standards, ISO 7498 describes the Basic Reference Model for
>networking. ...

Thanks for Networking 101.  I'm fully aware that the OSI model defines
CO and CL transport and network protocols.  We're talking about RPC, right?

>In an earlier posting, Mishkin had said:
>> I'm sure [OSF] will be acquiring OSI implementations though.
>
>They may be acquiring OSI implementations, but it's unclear what they'll be
>using them for. Adding OSI protocols to NCS would involve fundamental changes
>to its underlying architecture. NCS fails to fit the OSI connection-oriented
>model because it doesn't perform connect and disconnect handshakes. NCS also
>fails to fit the connectionless model--there are ACKs and REPs during the data
>transfer.
>
>If NCS developers have a committment to international standards, they should
>be using the OSI protocols for Session Management, Data Representation, and
>Application Control. None of these are present in the NCS2.0 product.

Get ALL your facts straight.  First of all, there's currently no ISO
standard for RPC.  Second, the protocol NCS 2.0 defines for running over
COTPs adheres as closely as possible to how we imagine such an ISO standard
will appear and fit into the OSI model.  This includes presentation
negotiation and the rest of the ball of mud.  Believe me, I've had
T-CONNECT through A-CONNECT up to my ears.

It is of course true that NCS does not support ASN.1/BER.  (For those
blissfully unaware of the ISO process, those are ISO standards for data
representations.)  In the opinion of the NCS architects and developers,
in the absence of any ISO standard (or even draft) covering RPC, it didn't
seem to make a whole lot of sense to be "standard" in the data rep front
when the rest of the protocol stack would be non-standard anyway.  You
don't make ISO people happy (REALLY happy, that is) by saying "Hey look,
I used ONE of your protocols here".  They want the kind of interoperability
that comes from having the whole protocol stack -- top to bottom -- defined
and implemented everywhere.  The Netwise RPC that includes ASN.1/BER
support is still (gasp!) proprietary in the eyes of the ISO world, in
spite of that support.

And since I suspect most of you out there (still reading anyone?) are
actually interested in reality (in addition to international standards),
bear in mind that it seems to be fairly universally recognized that the
performance of ASN.1/BER is pretty horrible in both time and space.

>In the words of the New Yorker: Block that Metaphor! The analogy does
>not work well. In case you hadn't noticed, Sun's RPCGEN has provided
>datagram-based RPCs for quite a few years.  Could you produce some (one)
>of these annoyed programmers?

Could you produce some (one) programmer :-)  Given the widespread
availability of Sun RPC on a variety of vendors' platforms, why aren't
there tons of Sun RPC based applications?

>Perhaps you've heard of NFS? 

The classic example of how a single, non-representative distributed
application has skewed the minds of thousands about what the appropriate
characteristics of a distributed application toolkit should be.  Yes,
millions USE NFS every day.  But NFS is just ONE APPLICATION.  Thus,
despite its obvious utility, it is still a sample of one.  We have no
reason to believe that the needs of the majority of the distributed
applications to come have much in common with the needs of NFS.

>Programmers need to understand about idempotent semantics to know when
>they can use a true datagram RPC; they also have to understand idempotent
>semantics when they're writing their NCS NIDL specification.

You've got it exactly right.  With NCS, programmers need to understand
things about RPC semantics.  With Sun RPC, they need to understand
things about network protocols.  I know which approach I'd pick :-)

-----------------

In <1990Jul20.034330.8152@athena.mit.edu> Phil Earnhardt (onecom!wldrdg!pae)
writes:

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

Let's get this straight.  The NCA book is a PROTOCOL SPEC, not something
application programmers use.  Users of TCP don't read RFC 793.  The setting
of the frag ack bit has the same relevant to application programmers
as the TCP ACK flag.

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

Ugh.  Suffice it to say that the spec should be taken with a grain of
salt when it comes to parameters such as the one you're pointing to.
We focused most of our energy on specifying the non-parametric aspects
of the protocol.  A correct implementation (e.g., NCS 2.0) would do round
trip time estimations.

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

You've found me out.  I'm actively hiding all my work from exactly the
people qualified to judge it.  Give me a break.  If everyone listened
to the right people at the right moment, Sun would never have gotten
away with sending 8K UDP datagrams (generally considered to be highly
poor form) in Sun RPC.  I'll put the NCA book on the Christmas mailing
lists for everyone in the IETF.

I have but one brain and 24 or so hours a day.

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

See above.

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

Yes.  You won't be able to make concurrent calls in environments that
don't support threading.  I also can't port my Unix programs that call
"fork" to MS/DOS.

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

I'll concede the "we give away source code for mediocre software" award to
Sun for RPCGEN.  I'll concede the "we managed to ship binaries of our
product on a fantastically large number of systems" award to Netwise for
RPC Tool.  I'll reserve the right to claim the "superior distributed
application development toolkit" award for NCS. (I can't comment on the
relative sizes of the systems since I don't know.)

If installed base were everything, we'd all still be typing things
like "//sysin DD *" on punch cards.

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

I guess I'm not sure what you mean, but if it involves doing a kind of
broadcast that goes through either MAC or network level bridges, my
understanding is that many (most?) people consider that to be
anti-social.  In any case, I think broadcast is a dangerous tool which
should be used carefully (i.e., not often).

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

How do I get the results?  In a synchronous call, the results are in
the output parameters defined in the procedure signature.  Do you create
some other random stub procedure that just has output params or what?
What if want to have more than one call executing concurrently?  How
do I coordinate and collect the results?  With the multi-thread /
synchronous call approach, the answer is create more threads and just
get the result via output parameters.

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

Not necessarily.  I might be collecting statistics about some remote
system.  Each thread makes a call to a different system and when the
result appear, the thread inserts the info (using mutex locks, of
course) into a common data structure.  No one is "checking for
results".    

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

Exactly.  See my comments above.  Are you telling me async RPC is OK
unless I want to do more than one remote thing at a time?  Seems sort
of a limiting model.

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

Asynchrony is hard to understand.  All the more reason to have a single
abstraction -- the process/thread -- to deal with it.  With a little
language support (especially for stack-based exception handling and mutex
locks) it's pretty tractable.  I recommend Andrew Birrell's DEC SRC tech
report on experience programming in such an environment (SRC Report 35,
"An Introduction to Programming with Threads").

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