Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This protocol is designed to facilitate communications for data collaboration and Web conferencing applications. The two roles understood by this protocol are client and server. This protocol could be used symmetrically across both roles. However, a small number of messages and actions are performed by a specific role, but need to be understood by both. A server (2) can be connected to multiple clients at a time, but clients do not have a direct way to exchange messages, unless the server (2) decides to communicate with them. A server (2) differentiates from different clients based on their transport connection.
This protocol provides a set of strongly-typed interfaces to be defined for both a server and client. These interfaces can be called remotely, as this protocol takes care of all parameter marshaling and method invocation. This protocol also provides a way to create an object hierarchy. These interfaces are allowed to connect and disconnect a child object, known as a distributed object. A distributed object is composed of the following parts:
The client-side distributed object peer.
Server-side distributed object peer components.
A concrete instantiation of a distributed object is allowed to send and receive messages to and from its peer when it is connected. There can be multiple instances of a distributed object at any time; it is analogous to a class definition and instance relationship. Each distributed object instance has a unique identifier that allows PSOM operations, as described in section 2.2.2, to be routed to them. This is known as a "proxy identifier".
A distributed object can exist without the distributed object that created it, and is allowed to exchange messages with its peer. Components on each individual client are allowed to communicate with each other, and all components on the server (2) can communicate amongst each other directly. This allows the creation of an object model where clients and the server (2) can exchange messages, and the server (2) can record the state of the conference and broadcast any changes to other connected clients via the distributed objects.
When a client and server connection is authenticated, distributed objects are logically connected so that they can exchange messages. Some distributed objects are connected when a user creates content; others exist in a given conference and have specific responsibilities. The connected distributed objects are allowed to exchange messages, which are defined by server and client interfaces for each distributed object. An example interface could be the existence of an sBroadcast message on the server interface and a cReceiveBroadcast on each client interface. When multiple clients connect to the server and logically connect the distributed object with this set of messages, a client could send an sBroadcast message to the server’s distributed object peer. When the server receives this message with a payload of data to broadcast, it could then call cReceiveBroadcast with that data on all clients’ distributed object for that given peer. This enables the construction of a distributed object model where clients and the server can exchange messages.
An interface is composed of a set of methods, which are also referred to as messages, and each method is allowed to have any number of parameters. The supported parameter types include:
String.
16/32/64-bit integers.
Floating point values, byte.
References to other connected distributed objects.
Arrays of basic parameter types and arrays of arrays.
For the full list of supported parameters, see section 2.2.
On the network, all byte orders are big-endian, unless otherwise indicated.
At a high level, messages sent as part of this protocol can be split into two parts:
Kernel: Handles connection, versioning, keepalive messages, and preparation to connect the application distributed objects.
Application distributed object: Allows Web conferencing components to exchange messages to perform user-related activities, such as sharing a document.
This abstraction extends into the way channels are used. A channel extended by this abstraction is a PSOM channel. PSOM channels are created by the client and have unique integer identifiers. PSOM channel zero, which is the initial PSOM channel, is created implicitly after connection. A PSOM channel provides a way for distributed objects to route messages to each other. Each PSOM channel has a root distributed object that provides a way to connect child distributed objects and exchange messages between peers. The following types of messages help route information:
Record messages: Deal with PSOM channel management and routing of inside messages to the appropriate PSOM channel.
PSOM operation messages: Enclosed in a record message. Contain the proxy identifier to route distributed object method invocation and connection operations.
The other PSOM channel used is PSOM channel 2, where all application distributed object messages are exchanged, as shown in the following diagram.
Figure 1: Overview of kernel and application channels
The protocol does not specify any explicitly-defined acknowledgement components. If an application-level distributed object chooses to add this functionality, it is outside the scope of the kernel and message protocol. Generally, low-level failures are indicated by a server (2) or client sending a special termination message and disconnecting. In some cases, either might disconnect in response to a protocol violation.
As previously stated, there can be multiple instances of a distributed object. The following figure shows a sample distributed object structure on PSOM channel 2. The root distributed object has only one instance, and two child objects of the same type. Each child can only exchange messages with the corresponding child peer.
Figure 2: Sample Application distributed object connection