ETech After AJAX: Low Latency Data to and From the Browser
Alex Russell, Jotspot
March 8, 2006

Contributors
==========================
Leon Chism - leon@chism.org
Gabe Hollombe - gabe@avantbard.com - http://avantbard.com/
<a href="http://zadrozny.com/nick">Nick Zadrozny</a>
==========================

Comet: Low Latency Data For Browsers

Ajax is _me_ driven
Social apps driven by _others_ too

Eyes on the user
    - the goal is responsiveness
    - ajax improves repsonsivness for
        - single user CRUD
        - write only interactions
        - read-only apps where lag is OK
    - the web is inherently multiuser
    - ajax is 1/2 the answer

To any user, the server _is_ other users

The Multi-user web
    - singel interaction updates are not enough
    - users in the same space need live updates of
        - their own changes
        - the changes of others
    - updates ot context affecdt avaialbe actions
    
If the web is a conversation, then stale conext kills.
    - things _have_ to update quickly, live.

context <==> latency

conversation mediums are defined by latency
    snail mail
    email
    irc
    sms
    IM
    phone 
    face to face
interuption level is part of the social context.

Wikis as a conversation
    -medium to high latency
    - not well suited to high-volume changes
locking  and overwrite issues
ajax allows more context to go stale
    - what else is changing while i edit?
    - who wants to break my lock?
    - have attachments been added
    - is the page itself changing?
made parts of the convo better, broke a lot of.
wikis _aren't_ a conversation without a lot of additional tools and work.

Conversations are event busses.
    - granularity - fine grained interfaces are more immediate.

broadcast is synchronization for "shared nothing" architectures.

"Comet"
    - let a browser open connection to server, have server push data as it happens 
w/out polling
    - long-lived http connections instead of polling
    - similarities to Ajax
        - no plugins
        - "plain old" HTTP
        - asynchronous
        - broad browser support
        - payload can be anything textual

Applications implementing Comet
    - GMail and GTalk
    - JotLive
    - Renkoo
    - Meebo
    - cgi:irc
    - KnowNow
    - others?

Clients poll to simulate push.
Different parts of the page go stale at different rates.

keeping up
    pushing state updates keeps ajax interactions and page context in sync.

How Comet Fights Lag
    - make sure that low-latency apps have low latency
    - avoids socket buildup and teardown
    - ajax + polling latency:
        - time since last polling request +
        - tcp and http request setup +
        - data transmission time
    - comet latency
        - transmission latency
    - lots of zombie connections (requires new styles of server architectures to 
detect and combat. tcp stack tuning?)

Transfer only the data you need exactly when the user needs it


what does a real time wiki look like?
    know who else is in/on the page
    ? why make wikis conversations?
    see other changes in the wiki concurrently.
    catch someone else making a change and have a conversation about it.
    
Implementation styles
    - long poll
        meebo, live page
        reconnect after every datagram
        server might package datagrams up
        simple to impl with xmlhttp
        won't do worse that polling, but can do better.
    - multipart xmlhttp
        no known system does the portably today
        similar to the forever-frame technique
        different delimiters for IE and FF, no Safari
? will browsers change to support this?
    maybe, but we don't need to throw out the old to get a new capability
? does the server keep a lot of sockets open?
    yes, but will discuss later.

    - the forever frame
        - frame or iframe
        - browswer incremental rendering hack
        - <script> blocks sent to iframe are evaluated after some soft of "flush" 
token tickes the browser
        - highly portable
        - allws connections to sub-domains
            - dcoument.domain
            - important in designing workable architectures

socket floods:
    - today's web servers won't stand up.
    - why subdomains are important. diff server.

Coment can reduce load
    - but not your current web server
    - poling is a latency/load trade-off
    - comet is an architectureal complexity trade-off
    - most of today's web servers use thread or procs
        - threads consume fixed resources
        - do not free them until the end of the connection
        - comet keeps them open for a _long_ time

wants event based web servers
    - os level
        kqueue -- freebsd
        epoll -- linux
    - network level
        POE - perl
        twisted - python
        yaws - erlang
        event_mpm (apache 2.2, unstable0
        Jetty ( java )
        light httpd uses kq and or epoll

the two connection limit
    - opening connections isn't as bad as opening processes on a server.
    - standard says you can only have 2 connections open to a single server from a 
single browswer concurrently.
    
Work arounds
    - multiplex
        - events for multiple components must come over the same connection
        - prevent creation of mult. tunnels
        - this is all old stuff that has been done before
    - dns hackery
    - flash
        - xmlSocket + flash 8 "externalinterface"
            flash 8 new feature
            not available on linux
            flash8 bridge to js is SLOW
is comet for me?
    do users collaborate on shared data?
    ...
    
Early design lessons:
    - work with interaction designers
    - learn from hyour desktop competition
    - be consistent
    - let users know why the data is changing
    - let users know who change the data
    - communicate connection failures clearly
    - push data updates, not functionality changes

Evolution, not Revolution
    - revolution was web apps (when we won)
    - now we just need to stay competitive, which is evolution

demo didn't work. "it was a port 80 thing".
AIM express used "forever frame" 5 years ago

done here...

=============================
Resources:
Presentation @ http://alex.dojotoolkit.org

__END__