Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!apollo.hp.com!mishkin From: mishkin@apollo.HP.COM (Nathaniel Mishkin) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <4b6999c3.20b6d@apollo.HP.COM> Date: 5 Jul 90 17:55:00 GMT References: <404@bischeops.UUCP> <4b423481.20b6d@apollo.HP.COM> <1990Jul5.040529.16093@athena.mit.edu> Sender: root@apollo.HP.COM Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 151 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