pae@athena.mit.edu (Philip Earnhardt) (07/05/90)
In <4b2772cd.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > I'm so glad that now there's yet another newsgroup (i.e., this one) I have > to read to make sure I don't miss something important :-) Pretty clever of > you-all to put the conversation someplace where I wouldn't look (as opposed > to, oh comp.sys.apollo or comp.protocols.misc or something). Not clever > enough though! > mishkin@apollo.hp.com > ^^^^^^^^^^^^^ 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. Conspiracy theory aside, you're probably right. This discussion does not belong on any manufacturer-specific mailing list. I'm cross-posting to comp.protocols.misc and suggest that we move the discussion there. > While there is certainly some truth to your comments about the problems > with the approach of building a reliable transport in user space, I think > most of them are tractable and tolerable in light of the benefits that > you get from using our approach. Many of these are described in my paper > you cited in your message. For example, the connection-based approach > imposes some penalties in connection setup and teardown. Obviously these > costs are amortized in case you make a lot of calls with that connection. > Unfortunately, we expect to see lots of clients that need to make a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > relatively few calls to a relatively large number of servers in turn. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > In this situation, the connection management overhead can be high. 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. How long does the server keep hold of the 200K of data? BSD implementations usually specify a worst-case round-trip delay of 1-2 minutes for the network, but a private network may have worse worst-case delay on some of its remote machines. Does the client send out an explicit ACK after getting a response to its RPC call? Does it do this on only non-idempotent requests? Can the server's queued data potentially grow without bound, or will it start refusing new RPC requests at some point? What is the worst-case delay that NCS assumes for a datagram? Could there be other assumptions about transport behavior that are wired into the NCS implementation? > However, it's really pretty hard for > me to believe that your datagram-based RPC is significantly (if at all) > cheaper than NCS's, assuming you specify (in NCS/NIDL) that the procedure > you're defining is "idempotent" (to make the comparison fair). All we > (and presumably you) do is send one message out and one message back. > The overhead of calling the OS to do the message I/O and the cost of > the message I/O dominate. 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. This may be picking nits, but I believe that the Netwise RPC will be the faster datagram technology. >>Mike: what will NCS2.0 do WRT broadcast? Will it be available with both >>types of transport? If broadcast is not available under connection-oriented >>transports, won't this constitute non-uniform transport behavior? >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. I'm not so facist as to refuse to let people use broadcast in >the datagram RPC system just because the people who define connection-based >transports aren't clever or ambitious enough to figure out how to support >broadcast in their protocols. 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. 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? 2. Are there any documents which describe the wire-level behavior of NCS on top of datagram-oriented transports: o What type of packets NCS is sending (UDP or IP). o When acknowledgments are sent. o How retransmission timers work--when are they used, what values are they set to, how the application can change the values. Also, there were several unanswered questions from the earlier posting: 1. What does NCS2.0 do in environments that don't support multiple threads? 2. Will OSF be using OSI protocols? If so, which ones? 3. What about availability: have any dates been announced? What platforms will be supported? Will the OSF DCE be available on non-UNIX systems? What about DOS PCs? 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.