FUNDAMENTALS OF DCP COMMUNICATION

MODES OF SERVICE

Like any application layer protocol or service, DCP resides on top of and depends on transport layer services for lower-level messaging.  Transport layer services may be categorized as either connectionless  or connection-oriented.  To provide flexibility and extensibility, DCP communication has been designed to take place over both connectionless and connection-oriented modes of service (MOS) on the transport layer.  

A connection-oriented MOS creates a virtual circuit, which gives the illusion of a physical communication path. It is a connection that appears to be point-to-point in nature.  A connection-oriented MOS is similar to a telephone conversation: the parties establish a connection, maintain the connection through the duration of their interaction and then terminate the connection.  For DCP, the virtual circuit remains intact through the duration of transactions and, optionally, through the lives of sessions.  Handshaking takes place within the transport layer to  guarantee the delivery of messages.  An advantage of connection-oriented MOS is the reliability provided by the transport layer in message delivery.  However, this is at the expense of greater associated overhead within the transport layer .  When guaranteed message deliver is desired, a connection-oriented MOS is preferred. 

A connectionless MOS provides communication in the form of a delivery service. It does not establish a point-to-point connection.  Since no form of connection is established between the parties, the transport layer services do not guarantee delivery.  A connectionless MOS can be compared to using a courier service:  the parties do not establish a connection, rather they communicate by sending each other messages via the service. Although there is no virtual circuit or guaranteed message delivery, DCP initiators and targets maintain state (or keep track of messages and of each other) through the use of session and transaction identifiers (similar to how couriers use tracking numbers).    Advantages of connectionless MOS include the ability to broadcast messages to the network at large and less associated transport layer overhead.  However, this sacrifices a transport that guarantees delivery.  Connectionless MOS is generally preferred when guaranteed message delivery is not required and light-weight or broadcast messaging is desired.  

Note: Although a connectionless MOS does not provide guaranteed delivery within the transport layer, DCP provides a set of robust facilities for tracking messages which allow a guaranteed delivery service to be implemented within the DCP application layer.

DCP employs UDP and TCP transport protocols for connectionless MOS and connection-oriented MOS respectively. The default port is 2500, but other ports may be used. This does not preclude DCP from being implemented on top of other protocols on the Internet, or on other networks. DCP only presumes transport layers that provide connection-oriented MOS and connectionless MOS. The mapping of the DCP message structures onto the transport data units of other protocols is outside the scope of this reference.

SESSIONS

DCP communication follows a session / transaction paradigm.  A session is a conversation between two resources.  DCP sessions and transactions can be compared to a conversation between people.  A session is like an entire conversation and transactions are like statements (or questions and answers).  Just as many statements are made by both parties in a conversation, many transactions can be made by both participants in a single DCP session.   A DCP conversation behaves as follows:

1. A DCP session with a target device is opened.

2. Any number of DCP transactions are made within the session.

3. The DCP session is closed.

The use of sessions provides numerous benefits.  These include:

• Less header data, because data that is pertinent to a session only needs to be sent once (when the session is created) rather than with each transaction, resulting in greater speed and less traffic.  

• Convenience of "pipelining" transactions through the session.  

• Flexibility in implementation.  

• A facility for hosting tethers and managing groups of transactions; when a session is closed, all pending transactions and tethers should be closed as well.

Sessions apply to both connection-oriented and connectionless modes of service and should not be considered the same as a transport layer connection.  Sessions are identified by the Session-ID header assigned by either resource when the DCP conversation is first started and may span multiple transport layer connections or datagrams.   All transactions that take place within the session must carry the session ID with them in the header data.  This provides a way of grouping transactions together and keeping track of them.  The DCP session provides implementation flexibility and allows the features of DCP to be supported in both connection-oriented and connectionless modes of service without degrading its capabilities. 

DCP makes use of special request header fields and response status codes for managing sessions.  Sessions may be managed explicitly and implicitly, friendly and unfriendly, and as an initiator or as a target.  The Session and Session-ID request message headers are used in conjunction with the  202 Keep-Alive and 203 Release response status codes to open and close sessions.  These message headers and response codes may be used within any transaction.  For DCP transactions that are initiated outside the scope of a session, the target must create a session and establish a Session ID before processing the transaction.

Detailed semantics for managing sessions are provided later in this reference.

TRANSACTIONS

A transaction is a piece of DCP communication that occurs within a session.  Many transactions can occur within a single session.  Transactions may be of an open-loop or closed-loop nature.  There are two general types of DCP transactions and each of these may occur in either direction (see figure below):

1. open-loop

2. closed-loop

Open-loop transactions are one-way communication scenarios that are initiated by one resource and processed by another. They do not include a response. This is similar to sending a check off in the mail and not receiving a receipt for it -- the sales loop is left open.  A closed-loop transaction is a two-way communication scenario that, in addition to the message that initiates the transaction, includes a response. This is similar to writing a check for something at the store -- you get a receipt and the sales loop is closed. Although both types of transactions may be implemented in either mode of service, connectionless modes of service allow transactions to be sent to the network at large. With the exception of discover requests, the default behavior for requests sent to the entire network is that they are open-loop transactions and should not be responded to.  Discover requests (which are always broadcast to a network) should always be treated as closed-loop transactions and should result in a response.  The default behavior for requests sent to specific hosts is that they are closed-loop transactions and should result in a response.  Through the use of the Transaction-Type request header, default behavior can be over-ridden.  Unlike the ubiquitous client/server model, the DCP model for communication results in resources that play more than one messaging role. DCP devices are likely to initiate and process both open-loop and closed-loop transactions.

Open-loop transactions should be used when a response is optional and it is unimportant to ensure that any specific resource processed the message.  One application for the open-loop transaction is to notify other devices when a minor device event occurs.  In a connectionless mode of service, these transactions may be sent to the whole network, notifying all DCP devices of an event.  If a response is needed or an acknowledgement of processing is desired, then the closed-loop transaction should be used.  Example applications for this type of transaction include querying or setting a device property, calling a device method, and sending critical event messages.

The basic building blocks of transactions are DCP messages.  They will be discussed later in the DCP Message section.