DBDE ObjCommProtocolRev.ppt - 1 Copyright 97/5/4 - RJLechner

IV. Object Communication Protocols

Client Catch Up Mode

Server Broadcast Mode

Active Client Communications

Aborted/Deferred Transactions

Join-Meeting Protocol

Download-Files Protocol

Broadcast-Update Protocol

DBDE ObjCommProtocolRev.ppt - 2 Copyright 97/5/4 - RJLechner

Client Catch Up Mode

1. During GetInfo, the server transfers current meeting status, file directory and access authorization information to the client.

2. During ViewInfo, the client decides whether and how to participate in the meeting.

3. UpLoad and DownLoad are file transfer modes. In the UpLoad state, the client may contribute a file to the

meeting repository as a future meeting agenda item. Version and revision controls may apply.

In the DownLoad state, the client may get a copy of any file in the meeting repository. If the file is active, a snapshot is taken as of the last server transaction sequence number. Access controls may apply.

4. Clients that download an active file will next enter the CatchUp state. This will transfer any remote update transactions since the downloaded snapshot. After that, the broadcast server is responsible for communicating with this client.

A history of previous broadcast transactions is retained by the server over a moving window of time, for use by clients joining the meeting during the CatchUp state.

DBDE ObjCommProtocolRev.ppt - 3 Copyright 97/5/4 - RJLechner

Server Broadcast Mode

1. The server supports this mode for all clients who join and have caught up to the current transaction activity on the meeting's active file.

2. Update transactions received from active local or remote clients are serialized and rebroadcast to clients who either passivlely monitor or actively participate in the meeting.

3. Round-trip delays are assumed negligible for wide-band local clients, but may vary widely for remote clients.

4. We allow remote active clients to 'work ahead' of the server to receive immediate visual feedback of their local drawing actions.

5. Exception: A request to create a new drawing object must wait for a globally unique object-id to be issued by the server.

DBDE ObjCommProtocolRev.ppt - 4 Copyright 97/5/4 - RJLechner

Active Client Communications• Active clients send messages requesting the server to accept local

updates. Each message from client to server has a name starting with CS.

• The first 3 arguments of each message are standardized as follows:CSEIid: The originator's event instance (EI)

identifier. CSETid:The globally-scoped event type (ET) identifier.

• Client update requests have the event type and name CSEDIT.

• Client update requests have three additional standard arguments:SCRTid: Reply event type identifier (for SCack reply).

CLNTid The originating client's identifier;<text>: The formatted record or set-field request

(arg-list)

• Control, timing and state change events have simple or no arguments.

• Local clients reply to broadcast updates with standard ack/nack replies.

• Remote clients do not reply to broadcast messages

• Client replies include the server- specified return event type:CSRTid: Return event type requested by the

server;

DBDE ObjCommProtocolRev.ppt - 5 Copyright 97/5/4 - RJLechner

Aborted/Deferred Transactions

Aborted transactions:

1. If a client transaction would lead to a 'race' condition or update conflict, the server will tag the transaction as 'rejected' and rebroadcast it.

2. The originating client, using two-phase commit, may then abort his premature (and all subsequent) transactions, and reapply them to his local database properly interleaved with remote ones.

Deferred transactions:

1. The server may tag a client transaction, which it broadcasts out-of-order, with a 'may not commute' warning to the originating client.

2. The client may optionally buffer all transactions received since the last local transaction which the server has echoed back over the broadcast channel, undo and re-do them in the proper order.

DBDE ObjCommProtocolRev.ppt - 6 Copyright 97/5/4 - RJLechner

Join-Meeting ProtocolJoin-Meeting Protocol

[The client requests to join the meeting over the global access channel:] CSJOIN(CSEIid, CSETid, CLNTid, SCRTid, meeting, access,data_rate)

[SCWAIT( ) * may be received while waiting for exclusive access to channel]

SCJOIN(SCEIid, SCRTid, CLNTid, meeting, limits, FILEid) [ack+join info]

[Client switches to file download mode to acquire meeting information:]

[server downloads meeting database (schedule, directory, etc.)]:

{SCINFO(SCEIid, SCETid, SCTR#, SCRTid, FILEid, <tableRow>)}+

[optional request by client to upload a file for later use in meeting]:CSUPLD(CSEIid, CSETid, CSTR#, CLNTid, CSRTid, FILEid)

[Server may send {SCWAIT}+ if ftp channel is busy:]

[Client uploads his file:]{CSDATA(CSEIid, CSETid, CSTR#, CSRTid, <tableRow>)}+

[Client is now ready to download the meeting’s active files.]

CLIENTInstance

SERVERInstance

(Event Trace or Object Interaction Diagram)

DBDE ObjCommProtocolRev.ppt - 7 Copyright 97/5/4 - RJLechner

Download-Files Protocol

CSOPEN(CSEIid, CSETid, CSTR#, CLNTid, SCRTid, FILEid)

SCOPOK(SCEIid, SCRTid, SCTR#, CLNTid, FILEid)

CSGETF(CSEIid, CSETid, CSTR#, CLNTid, SCRTid, FILEid) [file request]

[Server will send SCWAIT until ftp channel is available.]

SCDLOK (SCEIid, CSRTid, SCTR#, CSTR#) [Download channel available.]

[Client and server enter file transfer mode:]

{SCDNLD(SCEIid, SCETid, SCTR#, CSRTid, FILEid, <tableRow>)

CSACK(CSEIid, CSRTid, CSTR#, CLNTid, SCTR#) }+

[After downloading the file, the server sends recent updates:]

{SCUPDT(SCEIid, SCETid, SCTR#, CSRTid, CLNTid_src, CLTR#)

CSACK(CSEIid, CSRTid, CSTR#, CLNTid, SCTR#) }+

SCSYNC(SCEIid, SCETid, SCTR#, CSRTid) [End of updates to catch up]

CSACK(CSEIid, CSRTid, CSTR#, CLNTid, SCTR#) [acknowledge SYNC]

[The ftp channel is released; server switches client to broadcast mode.]

CLIENTSERVER

DBDE ObjCommProtocolRev.ppt - 8 Copyright 97/5/4 - RJLechner

Broadcast-Update Protocol

[A new user joins the broadcast protocol in passive (read) mode:]Server continues to send update broadcast stream to cllient:]{SCUPDT (SCEIid, SCETid, SCTR#, CLNTid_src, CSRTid, CSTR#, <text>)}

[Client requests to enter edit mode:]CSEDIT(CSEIid, CSRTid, CSTR#, CLNTid, SCRTid)

[Server returns permission to edit:] SCEDOK(SCEIid, SCRTid,SCTR#, CLNTid_src)

{CSUPDT(CSEIid, CSETid, CSTR#, CLNTid_src, CSRTid, FILEid) }*

[Local update echos are merged with remote updates and echoed back:]SCUPDT(SCEIid, SCETid, SCTR#, CLNTid_src, CSRTid, FILEid, <tableRow>)

[Client may leave via CSPAUSE, CSREADY, CSUPLD, or CSQUIT].

[Server may send SCWAIT, SCREAD, SCUPOK, SCNACK, SCQUIT]

CLIENT SERVER