@Section{The @Value(Name) Protocol} @Tag(protocol) @BlankSpace(1 line) @Value(Name) uses the Internet UDP (User Datagram Protocol), an unreliable datagram transport protocol, coupled with Athena's @I{Kerberos} authentication system to implement its transport layer. The @Value(Name) protocol is layered on top of this transport layer. The @Value(Name) protocol is an authenticated block stream protocol layered on a datagram protocol. Datagrams are assumed to be unreliable and unacknowledged. If reliable notice delivery is required then individual notices must themselves request that the receiver send an acknowledgement notice. All notices are considered atomic (whole unto themselves) and may not be fractured across datagram boundries. Packing and unpacking of notices into datagrams must be modular and properly abstracted. @Value(Name) clients and servers share a common transport layer library that provides routines for datagram packing, transmission, reception and unpacking. Notices are acted upon in the order in which they are received and unpacked. All notices share a common header format containing the notice type, time-to-live, class, instance, op-code and target. This header is called a notice-key. The notice-key is followed by a data area that is unique to all notices with similar notice-keys. All notices are routed, queued, parsed and acted upon by examining their notice-keys. In this way the notice specific data area need never be exmined except by @Value(Name) clients that specifically know how to parse notices bearing a particular set of notice-keys known to them. Each datagram may contains one or more notices with identical notice-keys. When multiple notices with identical notice-keys are to be sent they are packed into datagrams with a single copy of the notice-key, and as many integral notices as will fit, in each datagram. When the packed datagram is unpacked the notices are queued for dispatch and the notice-key is replicated for each individual notice as it is queued. In order to better understand how the notice-key is used for categorization and routing we should look at some examples and examine each notice-key element individually. Please refer back to the sample notice-keys in figure @Ref(nkeys) while reading the discussion which follows. @Begin(FullPageFigure) @Caption{Sample Notice-Keys} @Tag(nkeys) @Begin(Example, FlushLeft) @BlankSpace(0.5 inch) [Type:@^Time-To-Live, @\Class: Instance, @\Op-Code: Target] [REQUEST: @^0, @\SPINUP: "tony@@arilinn.mit.edu", @\ACCEPT_KEY: "ns1@@e40-server-1.mit.edu"] [REQUEST: @^0, @\WINDOW_GRAM: "tony@@arilinn.mit.edu", @\ACCEPT_KEY: "ns1@@e40-server-1.mit.edu"] [REQUEST: @^0, @\NS_FILTER: "tony@@arilinn.mit.edu", @\REDIRECT_KEY: "ns1@@e40-server-1.mit.edu"] [REQUEST: @^0, @\WINDOW_GRAM: "tony@@arilinn.mit.edu", @\REJECT_KEY: "ns1@@e40-server-1.mit.edu"] [REQUEST: @^0, @\SPINDOWN: "tony@@arilinn.mit.edu", @\REJECT_KEY: "ns1@@e40-server-1.mit.edu"] [INQUIRE: @^0, @\NS_HOST_MAINT: "ns1@@e40-server-1.mit.edu", @\STATUS_QUERY: "hm@@arilinn.mit.edu"] [INFORM: @^60, @\NS_NS_MAINT: "ns1@@e40-server-1.mit.edu", @\NS_UP: ""] [INFORM: @^60, @\NS_NS_MAINT: "ns1@@w20-server-4.mit.edu", @\NS_DOWN: ""] [INFORM: @^60, @\NS_HOST_MAINT: "ns1@@e40-server-1.mit.edu", @\HOST_DOWN: ""] [INFORM: @^0, @\LOGIN: "tony@@arilinn.mit.edu", @\USER_LOGIN: ""] [INFORM: @^0, @\LOGOUT: "tony@@arilinn.mit.edu", @\USER_LOGOUT: ""] [INFORM: @^0, @\HM_HOST_MAINT: "hm@@arilinn.mit.edu", @\STATUS_REPORT: "ns1@@e40-server-1.mit.edu"] [INFORM: @^0, @\PRINT_SERVER: "lps40-1@@e40-print-server-1.mit.edu", @\JOB_COMPLETE: "tony@@arilinn.mit.edu"] [INFORM: @^-1, @\WRITE: "tony@@arilinn.mit.edu", @\USER_MESSAGE: "mike@@hastur.mit.edu"] [INFORM: @^0, @\TALK: "mike@@hastur.mit.edu", @\TALK_REQUEST: "tony@@arilinn.mit.edu"] @End(Example) @End(FullPageFigure) @SubSection{Notice-Key: Type} A notice's type identifies what actions the @Value(Name) server or client will take immediatly upon receipt of the notice. It is intended to act primarily as a ``mode'' switch for @Value(Name) servers and clients. It is often helpful to think of each notice type as putting the server or client into a different mode. There are three types of notices: @Begin(Description) REQUEST@\REQUEST notices are sent when the sender wishes to request a @Value(Name) server database state change. They are propagated and require acknowledgement. The acknowledgement is in the form of a single INFORM notice who's format is know to both parties. INQUIRE@\INQUIRE notices are sent when the sender wishes to retrieve specific data from the target. They are not propagated and require acknowledgement. The acknowledgement is in the form of a single INFORM notice containing the data and who's format is known to both parties. INFORM@\INFORM notices are sent when the sender wishes to distribute information to @Value(Name) servers and clients on the network. They are not propagated and may only request acknowledgement if they have a single target (i.e., a non-null target field). If requested the acknowledgement is in the form of a single INFORM notice who's format is known to both parties. @End(Description) @SubSection{Notice-Key: Time-To-Live} A notice's time-to-live field identifies how long (in minutes) the @Value(Name) server should keep that particular notice in its queue. If a notice's time-to-live field is 0 then that notice is a one-shot; i.e., only those @Value(Name) clients who @I{currently} have notice-key requests that match that particular notice's notice-key will receive the notice. If the time-to-live field is negative then the notice is retained until such time as the server decides to discard it (this time should NEVER exceed 1 day). @SubSection{Notice-Key: Class} A notice's class identify which subsystem or client is responsible for its generation. For example, the login client sends LOGIN class notices, the HostManger client sends HOST_MANAGER class notices and the print server client sends PRINT_SERVER class messages. Extremely complex subsystems or clients may have multiple classes assigned to them (such as the @Value(Name) itself) but this is intended to be kept to a minimum. @SubSection{Notice-Key: Instance} A notice's instance identify which instance of a particular class (i.e., instance of a subsystem or client) is specifically responsible for its generation. Instances are composed of a network UID and the host that that UID is known to be active on. For example, all Athena user names are automatically network UID's and may be used in combination with a host name to identify an instance of the class USER_LOGIN. That is, a USER_LOGIN class message transmitted by user ``tony'' at host ``arilinn.mit.edu'' will have an instance of ``tony@@arilinn.mit.edu'' and so on. @SubSection{Notice-Key: Op-Code} A notice's op-code identifies the operation that the target is being REQUEST'ed to perform, being INQUIRE'ed about or being INFORM'ed of. @SubSection{Notice-Key: Target} A notice's target identifies the instance of a particular @Value(Name) server or client that the notice is destined for. If a notice has a null target (i.e., the null string ``'') then that notice is assumed to be a multi-cast notice to routed by the server.