6.826—Principles of Computer Systems 1999 Handout 24. Network Objects 1 24. Network Objects We have studied how to build up communications from physical signals to a reliable message channel defined by the Channel spec in handout 21 on distributed systems. This channel delivers bytes from a sender to a receiver in order and without loss or duplication as long as there are no failures; if there are failures it may lose some messages. Usually, however, a user or an application program doesn’t want reliable messages to and from a fixed party. Instead, they want access to a named object. A user wants to name the object with a World Wide Web URL (perhaps implicitly, by clicking on a hypertext link), and perhaps to pass some parameters that are supplied as fields of a form; the user expects to get back a result that can be displayed, and perhaps to change the state of the object, for instance, by recording a reservation or an order. A program may want the same thing, or it may want to call a procedure or invoke a method of an object. In both cases, the object name should have universal scope; that is: It should be able to refer to an object on any computer that you can communicate with. It should refer to the same object if it is copied to any computer that you can communicate with. As we learned when we studied naming, it’s possible to encode method names and arguments into the name. For example, the URL http://altavista.digital.com/cgi-bin/query?&what=web&q=butler+lampson could be written in Spec as Altavista.Query("web", {"butler", "lampson"}). So we can write a general procedure call as a path name. To do this we need a way to encode and decode the arguments; this is usually called ‘marshaling’ and ‘unmarshaling’ in this context, but it’s the same mechanism we discussed in handout 7. So the big picture is clear. We have a global name space for all the objects we could possibly talk about, and we find a particular object by simply looking up its name, one component at a time. This summary is good as far as it goes, but it omits a few important things. • Roots. The global name space has to be rooted somewhere. A Web URL is rooted in the Internet’s Domain Name Space (DNS). • Heterogeneity. There may be a variety of communication protocols used to reach an object, hardware architectures and operating systems implementing it, and programming languages using it. Although we can abstract the process of name lookup as we did in handout 12, by viewing the directory or context at each point as a function N -> (D + V), there may be very different implementations of this lookup operation at different points. In a URL, for example, the host name is looked up in DNS, the next part of the name is looked up by the HTML server on that host, and the rest is passed to some program on the server. 6.826—Principles of Computer Systems 1999 Handout 24. Network Objects 2 • Efficiency. If we anticipate lots of references to objects, we will be concerned about efficiency. There are various tricks that we can use to make things run faster: Use specialized interfaces to look up a name. An important case of this is to pass a whole path name along to the lookup operation so that it can be swallowed in one gulp, rather than looking it up one simple name at a time. Cache the results of looking up prefixes of a name. Change the representation of an object name to make it efficient in a particular situation. This is called ‘swizzling’. One example is to encode a name in a fixed size data structure. Another is to make it relative to a locally meaningful root, in particular, to make it a virtual address in the local address space. • Fault tolerance. In general we need to deal with both volatile and stable (or persistent) objects. Volatile objects may disappear because of a crash, in which case there has to be a suitable error returned. Stable objects may be temporarily unreachable. Both kinds of objects may be replicated for availability, in which case we have to locate a suitable replica. • Location transparency. Ideally, local and remote objects behave in exactly the same way. In fact, however, there are certainly performance differences, and methods of remote objects may fail because of communication failure or failure of the remote system. • Data types and encoding. There may be restrictions on what types of values can be passed as parameters to methods, and the cost of encoding may vary greatly, depending on the encoding and on whether encoding is done by compiled code or by interpreting some description of the type. • Programming issues. If the objects are typed, the type system must deal with evolution of the types, because in a big system it isn’t practical to recompile everything whenever a type changes. If the objects are garbage collected, there must be a way to know when there are no longer any references to an object. Another way of looking at this is that we want a system that is universal, that is, independent of the details of the implementation, in as many dimensions as possible.6.826—Principles of Computer Systems 1999 Handout 24. Network Objects 3 Function Independent of How Transport bytes Communication protocol Reliable messages Transport meaningful values Architecture and language Encode and decode Stubs and pickles Network references Location, architecture, and language Globally meaningful names Request-response Concurrency Server: work queue Client: waiting calls Evolution Version of an interface Subtyping Fault tolerance Failures Replication and failover Storage allocation Failures, client programs Garbage collection There are lots of different kinds of network objects, and they address these issues in different ways and to different extents. We will look closely at two of them: Web URLs, and Modula-3 network objects. The former are intended for human consumption, the latter for programming, and indeed for fairly low level programming. Web URLs Consider again the URL http://altavista.digital.com/cgi-bin/query?&what=web&q=butler+lampson It makes sense to view http://altavista.digital.com as a network object, and an HTTP Get operation on this URL as the invocation of a query method on that object with parameters (what:="web", q:="butler+lampson"). The name space of URL objects is rooted in the Internet DNS; in this example the object is just the host named by the DNS name plus the port (which defaults