🚀 go-pugleaf

In article <142133@sun.Eng.Sun.COM>, vipin@samsun.Sun.COM (Vipin Samar) writes:
> - how does the NCS library decide which transport to use.  Say, I have
>   both TCP and UDP on both client and the server machine.  Are there any
>   heuristics in place upon which you decide which transport has to be used?
>   Do you prefer one over the other?

The model (which is more or less the same for all versions of NCS) is
that when servers start up, they create some set of communication endpoints
with certain characteristics (in BSD-speak:  sockets of some socket type
and protocol in some protocol family with either a well-known or
dynamically assigned port).  The choice of characteristics can be
controlled by the server writer, or (at NCS 2.0) the server can say (in
effect) "create sockets of all protocol families and socket types that
both the RPC library and the underlying system support.  (You could
actually do this yourself in NCS 1.5, but we've made a simple function
to do it for you in 2.0.)

Once the server has created the communication endpoints, it advertises
the locations (essentially sockaddrs) of these endpoints in some network
accessible database.  NCS 1.5 supports the Global Location Broker for
doing this.  NCS 2.0 (OSF DCE RPC) works in conjunction with a distributed,
hierarchical name service.  Both the GLB and the name service can store
locations.

Now for the client side of things.  Presumably, a client has some abstract
identification for the server it's trying to reach.  E.g., it may have
an "interface ID" (what Sun RPC calls a program number, I think), or
it may have a pathname in the distributed name service, or it might have
some sort of "object ID" for the object (e.g., database, printer, file)
that it wants to operate on.  Whatever this abstract ID is, the client
contacts some 3rd party service (like the GLB or the name service) (which
typically it uses broadcast to locate) to translate the abstract ID into
a set of locations of servers.

Once the client has the locations, it picks out the ones that it can
use.  (Like sockaddrs, the stored locations hold information about the
network protocols you need to use to talk to the server at that location.)
This "picking out" step happens transparently to the client.  (More
transparently in 2.0 than in 1.5.)  The client application (or client
stub, in case you're using one of the fancier automatic binding features)
then presents a location to the RPC runtime which returns a "binding
handle" to the client.  The client then makes remote calls using the
binding handle.

(BTW, NCS currently has no way to pick among an apparently equivalent
set of locations.  This is an area for future work.  E.g., you might
want to favor TCP over X.25, if both are available; you might favor servers
on the same network as you, if they exist.  Some of these schemes are
hard to formalize and/or implement given existing underlying technology.)

At no point does the client express anything like "use TCP", or "use
connection-based RPC", or the like.  All that information is encapsulated
in the location structure and used transparently by the RPC runtime to
dispatch to the appropriate RPC runtime code to run the appropriate network
protocols (from RPC down through transport).

> - Using UDP for hundreds of connections is a good idea, but I wonder whether
>   to support streaming on top of that is  a good idea because it can lead
>   to all sorts of rate-flow problems.  TCP is great at backing off in
>   stormy and overloaded networks, while UDP just exacerbates the problem.

I guess I'm not sure what your point is.  NCS uses a flow control protocol
on top of UDP.  I.e., NCS uses UDP in much the way that TCP uses IP.
Thus, virtually all the tricks that TCP uses are candidates for being
used (and many are used) by NCS.

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