CUPID

Consortium for University Printing
and Information Distribution

Protocols and Services (Version 1):

An Architectural Overview

CUPID Servers

The CUPID Architecture defines two kinds of Servers: Origination Servers and Notification Servers. These terms refer both to the software (in UNIX terms, the daemons) that provides the specified services and to the computers upon which this software is running. A single computer could, of course, operate as both an Origination Server and a Notification Server.

Communication with and among CUPID Servers utilizes a reliable byte-stream protocol such as TCP/IP as a transport mechanism. In a TCP/IP-based implementation, for example, Origination and Notification Servers would operate on separate designated Ports, which would be registered with the Internet Engineering Task Force. As Internet protocols evolve, CUPID will continue to operate on whatever new transport layer emerges. It is also likely that the CUPID Architecture will prove readily implementable on proprietary networks.

Almost all CUPID activity is centered around the Origination Server. CUPID Notification Servers exist solely as a means for CUPID Printshops to register their capabilities and to receive notification of incoming work.

Version 1 of CUPID does not provide for a wide-area directory of CUPID Printshop capabilities other than what can indirectly be obtained through the CUPID Address Map (see Section 2). Future versions of CUPID may utilize emerging network information services to "advertise" the identities of CUPID Printshops over the Internet. Such a service will allow Publishers to "shop around" for Printshops that provide the facilities required for a particular Printjob at acceptable terms.

CUPID will evolve over time. CUPID protocols, however, will be defined so that Clients and Servers using different levels of the protocols will be able to interoperate to the greatest degree possible.

Communication among CUPID Servers and Clients assumes that the daemons responsible for Origination and Notification Servers are constantly running, but that a particular Client may or may not be operating at any point in time. Server-to-server communication, using CUPID Interior Protocols, is thus straightforward (but see below). For Client-Server communication, using CUPID Exterior Protocols, there are two cases: Client-initiated and Server-initiated. In the case of Client-initiated communication, the Client typically connects to the Server, requests information and/or issues commands, and eventually disconnects. Because the Client can assume the Server is always accessible, no special provisions are needed. When a Server, on the other hand, wishes to initiate communication with a Client (in order, for example, to inform a Publisher that part of a Printjob has completed), it is possible that the relevant Client is not currently running or not connected to CUPID. Such communication needs are managed by associating a CUPID Message Queue with each Printjob. The Message Queue resides on the Origination Server for that Printjob, and accumulates Messages related to the Printjob that are targeted for the Publisher, the Printshop, and any Agents referenced by the Printjob. A Client connecting to a Server may request the accumulated messages for the appropriate Publisher, Printshop, or Agent. Future Versions of CUPID may allow Publishers, Printshops, and Agents to be notified via electronic mail that one or more CUPID messages are waiting.

Although it is assumed that Origination and Notification Servers are constantly running, network interruptions and other instabilities may temporarily disable communication with a given Server. Each Server and Client must therefore be prepared to find that any other Server is inaccessible at any moment. The amount of time allowed for recovery in such situations will be left to developers, along with issues of how such time limits may be configured by CUPID system administrators and users.

---

	Developed & Maintained by: webmgr@cni.org	© 2008 Coalition for Networked Information ALL RIGHTS RESERVED.
Any comments, or feedback?		Last Update:   Wednesday, 03 July, 2002 - 04:22 PM - EDT