🚀 go-pugleaf

In article <1990Jul5.040529.16093@athena.mit.edu>, pae@athena.mit.edu
(Philip Earnhardt) writes:
|> In <4b2772cd.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel
Mishkin) writes:
|> Oh, no! The plot has been uncovered: keep Mishkin from seeing the
postings by
|> putting them on comp.sys.hp. The mind boggles at the diabolical
nature of this
|> conspiracy! Never mind that Mishkin works for HP, or that this list
has gotten
|> many Apollo mailings since the takeover, or even that markl@hpbbi4.HP.COM
|> (Mark Lubfkin) was the one who started the thread.

OK, OK.  I could have seen this coming.  It's just that keeping up with
the multi-100 articles/day on rec.arts.startrek has gotten me down.  I
promise to be a good boy and read all the mail about the vices and virtues
of HP-UX from now on :-)

|> This is a scenario that I don't understand in NCS. What if, say, 100
|> different clients each make a single non-idempotent call to a server
|> (and then go off and talk to different servers). Say that each of the
|> calls returns 2K of data to the client. Since the calls are
|> non-idempotent, the server is required to hold each client's response
|> until it is acknowledged.

The basic idea is that the client ack's the response either implicitly
(by making another call to that server) or explicitly (by sending an
explicit "ack" message).  The implementation defers sending an explicit
ack for a few seconds (in case the client is in fact making multiple
back-to-back calls to the server).  The server retransmits the response
periodically until the response is acknowledged.  Upon receipt of a
duplicate response, the client retransmits an explicit ack (assuming
that a previous transmission of the explicit ack got lost).  (It was
a bug in 1.5 that this last step didn't happen.)  If all else fails and
the server never hears an ack from the client, the server will discard
the response after some period of time (currently 30 seconds).

Maybe I'm wrong, but I don't think any of this can be fundamentally better
for TCP/IP.  If I have 100 connections open and I've written 2K of data
to each of them, my buffer usage is tied to each of the client's
ack'ing in a timely fashion the data I've sent it.  In practice, I'd
think, TCP/IP is going to be worse in dealing with this scenario.  First,
I'm consuming valuable kernel resources in the form of these 100
connections (TCBs).  (I wouldn't be surprised if most Unix kernels were
configured in a way so that if a single server consumed 100 TCP
connections, it would be using a large fraction of all the TCP connections
allowed for the whole system.) Second, all the unack'd data has to live
in wired kernel mbuf's, whereas NCS's buffers are in (page-able) user
address space pages.  (I suspect that what's really going to happen if
you use TCP/IP is that one of the "send" system calls is just going to
block awaiting the availability of an mbuf.  Needless to say, this would
be disasterous from the RPC library's point of view.)

|> The messages on the wire are going to look pretty similar to each other.
|> However, my understanding of the NCS implementation is that you have a
|> separate thread that processes the receipt of data/data
reassembly/request for
|> missing data fragments. At the very least, NCS will have the added
overhead of
|> an extra context switch on receipt of the client and server messages to get
|> the message to the appropriate thread.

The cost of the context switches is in the noise compared to the cost of
the message I/O and making calls to things like "select" and "recvfrom".
When someone gives me an environment where the local OS doesn't consume
unseemly amounts of time doing fundamentally nothing, I'll worry about
things like context switch overhead.

|> >Geez, cut me some slack.  I will arrange that the manual has a skull
|> >and crossbones around the section that describes the broadcast feature
|> >of RPC. 
|> In case you missed the point, it was the OSF DCE Rationale that says that
|> uniform transport behavior was one of its criteria for selection.  If you're
|> saying that's a silly concept, I'll agree with you. I would be interested in
|> hearing your ideas on how broadcast should work in, say, TCP/IP.

Everything is a matter of degree.  Broadcast is a feature that a relatively
few (and hopefully almost no) applications need.  At-most-once call
semantics is a feature that a relatively large (possibly almost all)
applications need.  Thus, making the former a function of transport choice
can be considered tolerable.  Making the latter such a function seems
unwise.

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

Time will tell about what the right recommendations to make are.
I would like to believe that things will turn out so that I can say "Use
COTP only when there is no CLTP available".  An RPC expert made the
argument to me that I should say "Use CLTPs in LANs and COTPs in WANs"
because getting an RPC/CLTP to work right in a LAN environment is easier
than getting it to work right in a WAN environment.  Maybe he's right.
However, I'd like to think that there's not black magic here that would
prevent me from doing what the COTP does over WANs.  But maybe it'd turn
out to not be worth the effort.  Like I said, time will tell.

|> 2. Are there any documents which describe the wire-level behavior of NCS
|>    on top of datagram-oriented transports:

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

|> Also, there were several unanswered questions from the earlier posting:
|> 
|>   1. What does NCS2.0 do in environments that don't support multiple
threads? 

The NCS 2.0 implementation currently depends on threads.  We made this
choice with our eyes open.  It was simply a tradeoff between what we
felt we could get done with what set of tools.  I believe that this choice
will not be problematic for Unix environments, as POSIX is standardizing
on a multi-thread interface (PThreads), and OSF chose a portable
implementation of PThreads (CMA from DEC) as part of the DCE selection.
I don't believe OS/2 should be a serious problem since it already supports
multi-threading.  That leaves MS/DOS.  I believe getting this one taken
care of is only a matter of time/money and expertise.

|>   2. Will OSF be using OSI protocols? If so, which ones?

I don't know what OSF's plans are for delivering support for the OSI
protocols.  I'm sure they will be acquiring OSI implementations though.

|>   3. What about availability: have any dates been announced?

I'm afraid I don't recall the content of OSF's public statements.  I
believe they said words to the effect that stuff will be available in
'91.

|>      What platforms will be supported? Will the OSF DCE be available on
|>      non-UNIX systems? What about DOS PCs?

OSF sells source.  The source they sell should be widely portable to
Unix systems, as that's OSF's target market.  I imagine the source will
be largely portable to VMS because of DEC's involvement in the project.
I don't know what OSF's commitment is to DOS.  I'm sure they understand
the wisdom of supporting that environment.

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