Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!decwrl!ucbvax!bloom-beacon!pae From: pae@athena.mit.edu (Philip Earnhardt) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <1990Jul10.224543.20314@athena.mit.edu> Date: 10 Jul 90 22:45:43 GMT References: <4b423481.20b6d@apollo.HP.COM> <1990Jul5.040529.16093@athena.mit.edu> <4b6999c3.20b6d@apollo.HP.COM> Sender: onecom!wldrdg!pae Organization: Netwise, Inc. Lines: 144 In <4b6999c3.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > 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.) Actually, things should work pretty smoothly under TCP. Since the connection is being maintained by the kernel, the acknowledgment can be sent immediately after the packet is processed by the kernel. NCS would have the ack sent out 3 seconds after the user process has processed the data. Also, acknowledgments can be sent back to the server for fragments of the message. It's probably not necessary to understand all the nuances of the NCS implementation in order to understand the fundamental problem with a connection-oriented protocol implemented outside the kernel on top of a datagram transport. The kernel has access to real-time resources that are not available to user processes. There may be multiple network interfaces for a transport on the same system that can support different datagram sizes--the user process doesn't need to understand these differences to efficiently use a transport. There are undoubtedly some implementations of NCS that will work reasonably well for a given networking configuration, but will not work for the general case. If the connection-oriented scheme at the user level were the way to go, why isn't everyone else jumping on the bandwagon? Why not implement X that way? Are there any RFCs that discuss the NCS technology? Have any of the Internet gurus endorsed it? > Everything is a matter of degree. Broadcast is a feature that a relatively > few (and hopefully almost no) applications need. ^^^^^^^^^ ??? In order for your GLB to work, you need broadcast. |> 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 :-) I had already looked through this book. I hadn't found answers to the specific questions I had asked: o What type of packets NCS is sending (UDP or IP). o When acknowledgments are sent. (there's some information about the timers, but there's no timeline charts about what goes down the wire.) o How retransmission timers work--when are they used, what values are they set to, how the application can change the values. > 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. There's the Mac, Atari, and other types of personal computers. Some of the mainframe environments don't have anything like threads. Many of the older UNIX systems don't support multiple threads. There are lots of other types of workstations, minicomputers, and proprietary turnkey systems that fall through the cracks. Finally, the NCA book mentions "small, embedded microprocessors used in real-time data acquisition environments" as a potential platforms for NCS. For these systems, there will have to be modifications to the OS to support multiple threads (I assume non-preemptive application-provided multithreading won't work). There's the added expense of a new OS and the hassles of configuring/installing the system software. 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? In <4b69b513.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: >> 3. In a complex network, there may be serveral subnets. Customers need >> to have control of the granularity of their subnet broadcasts--they >> may want to talk to a GLB that's available on their local subnet, >> or they may want to talk to GLBs on other subnets. Does the LLB/GLB >> scheme provide control of the granularity of broadcasts? > First of all, it IS possible to have multiple disjoint GLB database in > a single environment. > [discussion of NCS naming flexibility deleted] The response didn't seem to address the issue raised. How exactly does one specify the granularity of the broadcast? In <4b69c9e1.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > Async RPC is another one of those religious issues. 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. > [Discussion of the merits of implementating multi-threading ommitted.] 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. On the other hand, I think multiple threads are much more complex. All procedures must be reentrant--all non-stack data (globals and static variables) must either be: o read-only or o written only by one thread (and typically can't even be read by other threads unless the datum is simple) or o protected by environment-specific mechanisms that lock out other threads while the data is being modified. This is nasty stuff. There is no automatic mechanism (e.g. an option to lint) to determine if a given module is reentrant. If the code is non-reentrant, the kinds of problems that crop up are timing-related--they will be non-repeatable and probably undebuggable. For UNIX systems, the thing that makes more sense is fork(). Data segments are shared between the processes *until* one of them decides to write data. That page is then copied and the process that wrote to it keeps the copy. If data really needs to be shared between the processes, one of the UNIX-suplied inter-process communication mechanisms (or maybe even RPC ;-) could be used. It does cost a bit more than multiple threads, but you will wind up with lots more hair in your head. I'm not suggesting that NCS would be better off using multi-tasking for implementation of its pseudo connection-oriented protocols. Implementing fork() and copy on write would be tricky on a lot of today's platforms. I do feel that asynchronous calls are far easier to understand than multiple threads. 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.