Games, chat, and finance Toward a truly interactive web with Comet, BAM, and HMTP Emil Ong Chief Evangelist.

Games, chat, and financeToward a truly interactive web withComet, BAM, and HMTP

Emil OngChief Evangelist

Caucho Technology

Resin has been around for 10 years Over 8000 customers, even more open source

users User base consists of both early and

conservative adopters Now the top Java web server in NetCraft

http://survey.netcraft.com/Reports/200805/ 340,000 domains

Groundbreaking Innovations

Hessian web services protocol Top clustering implementation Quercus: PHP in Java Server-push And now... a revolutionary approach to the

interactive web

The Interactive Web

Common properties

1) Sessions are long-lived

2) Must be responsive/ real time

3) Must not overburden server

4) Communication is bidirectional

Killer apps Games Chat Finance

The Interactive Web with HTTP

1) Sessions are long-lived

2) Must be responsive/real time

3) Must not overburden server

4) Communication is bidirectional This is harder with HTTP

Comet has shown thisis possible

Simulating Bidirectional Communication with HTTP

Client generated events are easy They are simply requests

AJAX just makes those requests without changing the page

What about the other direction?

Sending events from server to client using HTTP

Polling Requests at regular intervals that complete

immediately Long Polling

Requests that wait for the next event, then restart Server-push (Comet)

Socket held open with streaming updates from the server

Techniques compared

Advantages Disadvantages

Polling ● Easy to do inbrowser now

● Event impedancemismatch

● Socket construction/teardown

Long Polling ● Easy to do inbrowser now

● Less likely to missevents

● Taxes most currentservers

● Socket construction/teardown

Server Push ● Possible in browsernow

● Unlikely to missevents

● Many servers notprepared

● No standardprogramming model

Server-Push (Comet)

Current hot technology Implementations

Resin Grizzly (Glassfish) Jetty Tomcat

All solve the problem of threads dedicated to a socket

All have a different programming model

The problem of Bidirectional Communication with HTTP

Different techniques for send and receive Use AJAX to send data from client Use Comet to receive data on client

Two connections required* Places limitations on TCP that were necessary

for scalability in the past A necessary evil at the moment

Truly Interactive Communication

Must be capable of long-lived connections Must be responsive/real time Must not overburden server Must be bidirectional Must have a simple, coherent API/architecture

Creating the architecture

Start with the communication patterns Messages Request/response

Truly bidirectional communication Client -> Server Server -> Client Both must be supported in both patterns

Creating the architecture

Representation of entities Agents

Bidirectional communication implies that clients are first class citizens

Agents represent both clients and servers A broker manages communication between

agents

Brokered Agent Messaging (BAM)

Broker Handles communication between

agents It's not CORBA

Agents Represent both clients and services

Messaging Messages Request/response (asynchronous)

Example: Sudoku

Demo

Client 1

Resin

Broker

Client 2

LoginQuery Client

Agent 1

LoginQuery

ClientAgent 2

Logging In

SudokuService

Game 1

AvatarAgent 1

Client 1

Resin

Broker

Client 2

ClientAgent 1

ClientAgent 2

SudokuService

StartQuery

WaitResult

StartQuery

AvatarAgent 2

StartResultStart

Message

Starting a game

Game 1

AvatarAgent 1

Client 1

Resin

Broker

Client 2

ClientAgent 1

ClientAgent 2

SudokuService

MoveQuery

AvatarAgent 2

MoveMessage

MoveResult

Making a Move

Game 1

AvatarAgent 1

Client 1

Resin

Broker

Client 2

ClientAgent 1

ClientAgent 2

SudokuService

MoveQuery

AvatarAgent 2

MoveMessage

MoveResult

Game overMessage

Game overMessage

Ending the Game

Design notes

Agents can be long-lived SudokuService Client

Agents can be short-lived SudokuAvatar

Agents are lightweight and dynamic Non-agents can interact with the system

SudokuGame

Code sample: SudokuAvatar

public boolean sendQuerySet(long id, String to, String from, Serializable value) { if (value instanceof MoveQuery) { MoveQuery query = (MoveQuery) value; MoveResult result = _game.move(query, getJid());

_broker.sendQueryResult(id, from, to, result); return true; ...

BAM API

void sendMessage(String to, String from, Serializable value)

boolean sendQueryGet(long id, String to, String from,

Serializable query)

boolean sendQuerySet(long id, String to, String from, Serializable query)

Address space

Agent names look like email addresses: [email protected]/3

First component: service name (sudoku) Second component: domain (caucho.com) Third component: instance identifier (/3) Address structure reflects lightweight nature of

agents

Hessian Message Transfer Protocol(HMTP)

Wire protocol on which BAM is based Uses Hessian for compact serialization Evolved from XMPP (Jabber)

Target platforms

Flash/Flex Silverlight JavaFX Java Applets Comet (interim) Java Quercus (PHP) .NET

Conclusion

Interactive applications will become more common

HTTP is not sufficient to handle them BAM outlines a new architecture and API to

make the development of these applications easier

What's next?

Technical Convenience functions Making a PHP page a BAM service HMTP standardization

Promotional Game contest

Thank you!

Questions? Comments?

More information

http://hessian.caucho.com/ http://blog.caucho.com /

Appendix: Bridging BAM and Comet

Initial Comet request creates agent Agent triggers event to client on messages On AJAX requests, pull agent name from

session