Transport between client and server

The transport of data between the client and server is based on HTTP (no direct TCP or UDP) and there are a number of alternatives to how to solve this problem.

Client and Server communication

The "normal" way of doing the communication in Ajax is to open a new HTTP request for each interaction. This obviously creates problem if you are waiting for data to come from the server so you open a request that blocks until the data is available. The new data is then downloaded and the process restarts. This creates a scalable solution on the server side where it doesn't have to dedicate a socket and handler to each client. The drawback is that there might be increased delay between the client and server. A special case (an optimization) is to close the connection on the server side if no data is available and let the client try in a short while again, so called polling.

To get faster response times the client can keep the connection open to the server "for ever" and use the same connection for both ways of the communication. This will require good handling on the server side of many sockets. Alex Russell calls this Comet and discusses this on his blog and how it is implemented in Dojo since a year (March 2006).

In step one we will go with the first approach, the classical Ajax and see the others as an optimization that we will introduce later on.

The Server

The server part can be solved in various ways as well:

1. Integrate JSP code into the Marratech client to let it act as a gateway.
• Requires a JSP capable web server integrated into the client.
2. Reuse the JSP engine in the Marratech Manager and write a gateway inside the Manager.
3. Do it standalone with a fake server supporting JSP.
4. Do it without JSP at all. That is, just use HTTP as a carrier and do a proprietary protocol for transferring the data.

We will go with approach 4 for now. We will reuse the old HTTPServer I wrote back in the day (around 1997).

The Protocol

Everybody needs a protocol.

The are two main parts, the general communication between the client and the server and the media specific communication.

For the general communication we propose the following protocol (which most likely will be updated in the future):

Request will be handled via HTTP GET as a command to thelma?cmd=Y&session=Z&a=A where X is the media and Y is the command, Z is the sessionid and A is a specific argument which can be repeated and is specific for each command. The sessionid is retrieved via open session command.

Because we want to have a self contained communications protocol, responses will be handled inside the protocol and we will not rely on the HTTP response mechanism. The reason is to later be able to move to other transport mechanisms for the communication.

Version handling is not an issue as the client code is downloaded on demand (via JavaScript from the server) and thus us always updated to the latest version. The special case of updating the code and an invalid request being noticed, will be handled by the reset response.

WORK IN PROGRESS

Global command list:

• open = open session
  • Args:
    • [ sid = number | stitle = title ]
      • sid is the session id as defined in the Marratech Manager for each Marratech e-meeting room.
      • title is the room title. In the unfortunate case of two rooms having the same name, the first found on the server will be used.
        • sid or stitle can be used.
    • media = media
      • The media this connection should handle.

Media list:

• ctrl = Control
• chat = Chat
• audio = Audio
• video = Video
• wb = Whiteboard
• web = Web
• member = Membership

Global answers:

• fail = Failed
• ok = Success
• reset = reset
  • Reload everything. Note might create problems with caches!