🚀 go-pugleaf

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.