Interoperability Communication

From MemberWiki

Jump to: navigation, search

Contents

Ajax Interoperable Messaging

Introduction

This paper is a working document to create a proposal for the inclusion of messaging services in the OpenAjax Hub.

Terminology

We need to decide which of the terms we are going to use for server to client comms. Is there support/understanding of the Comet name? Is Ajax Push a better name for Open*Ajax*? Is it just "Comet" or "Ajax Coment"

  • Ajax Push
  • Comet
  • Long Polling
  • Messaging

Objective

The objective of this document is to:

  • Identify the problematic use cases of Ajax messaging
  • Discuss the issues and possible solutions
  • Propose a set of requirements for a messaging solution to be included in the OpenAjax hub.

Technical Background

While non-HTTP based communication and messaging is possible from Ajax-like clients, they do not fall within the charter of the OpenAjax Alliance. For the purposes of this paper, we restrict our consideration to messaging that is transported over standard HTTP.

Client to Server Messaging

blah blah blah

Server to Client Messaging

Ajax Server to Client messaging mechanisms over HTTP are all based on one or more of the following techniques

Polling 

The client periodically makes a request to the server to query for events. This technique faces a trade off between latency from infrequent polling vs wasted bandwitdh and CPU for frequent polling.

Long Polling 

Long Polling is one of the names for a polling technique where the server will hold onto a poll request for a period of time, while waiting for an event to occur. When an event occurs on the server, a response is sent to the client. The client will issue a new poll request for further events.

Streaming Response 

The response to a client poll is held open, so additional chunks of data may be streamed to the client.

Combination 

A combination of all three techniques may be used, with client polling delays, server event delays and response streaming.

Problematic Use-Cases

Ajax Push framework interoperability

scenario
two or more Ajax Push frameworks within a single Ajax client application.
issue
Each frameworks initiates a long poll and consumes the browsers per host connection limit.
comment
A mechanism to share long poll requests may be required.

Ajax Push multi tab/window usability

scenario
An Ajax Push based application is opened in two or more tabs/windows of the same browser.
issue
Each instance of the application is unaware of the others, initiates its own long poll and thus consumes the browsers per host connection limit.
comment
A solution to detect/handle multiple instances may be required.

Server side Ajax component interoperability

scenario
An server uses portlets or server side mashups to combine multiple Ajax components into a single page/application.
issue
The client side components will be unaware that the page URL is shared by other components and frameworks and may attempt to use the source URL to communicate with their server-side components. The portlet or mashup will not be able to differentiate requests targetted as component to component communications vs requests to refresh the entire page.
comment
A mechanism to address messaging to components may be required that can pass portlets and mashups without knowledge of the Ajax frameworks.

Service side Ajax component efficiency

scenario
An Ajax application that is composed of multiple components with server side elements.
issue
Some event on the client side may cause all those components to attempt to refresh their state from the server side, so multiple requests to the server will be made and significant latency may be experience.
comment
A batching mechanism may be required.

Discussion

Connection Limits

  • Browsers commonly have a 2 connection limit per every host they connect to. These connections are shared between all uses on the browser and if a connection is in use, the requests are pipelined or queued waiting for the outstanding requests to complete.
  • Two HTTP/1.1 connections is sufficient for efficient two-way messaging
  • The use of Ajax Push techniques puts significant additional load on network infrastructure. Traditional web applications typically have less that 0.1 requests outstanding per user. For Ajax Push, this increases to over 1.0 request per user and thus represents at least a 10 fold increase usage of network resources.
  • Increasing the per host connection limit is not a satisfactory solution as an increased limit
    • is not justified on messaging needs.
    • will further increase network and server load
    • will only delay rather than avoid resource starvation.

Multi window/tabs

  • Windows/tabs cannot communicate with each other, so it is impossible to share connections without browser support.
  • Browser support for sharing connections is closely linked to requirements for browser support for XSS.
  • A server can detect if multiple long polls are coming from the same client and gracefully fail: either by falling back to polling or informing user of the duplication.

Cross Site Messaging

The XSS "hacks" available for Ajax Push require significant support from the server side so that script can be injected. It will be difficult to get general acceptance of such techniques.

XmlHttpRequest "investment"

There is significant investment in the use of XmlHttpRequest for Ajax applications in terms of:

  • frameworks, tools and examples
  • Documentation, books and articles
  • mind share

Any messaging solution proposed by the OAA will be accepted more readily if it is similar to XmlHttpRequest:

  • asynch API
  • supports multiple content types
  • supports headers as meta data.

Existing protocols

These are existing protocols with HTTP transports in the Ajax messaging space or in related fields.

Jabber/XMPP

SIP

Bayeux

BEEP

WHAT WG SSE

JMS

ABC

Ajax Bidirection Communications My favored name for a OAA protocol

HTTP Compliance

The technique of using a streaming response has been described as "protocol abuse" and has several issues:

  • A proxy or transparent proxy is entitled by HTTP to buffer a response until either the entire response is received or it's own buffers overflow. There is no guarantee that a flush from a server will result in data arriving at the client.
  • Browsers often have internal buffers that need to be exceeded before content is processed. A common technique is to follow data with quantities of white space. This padding is wasted bandwidth and can be expensive in environments such as mobile.
  • TCP/IP is normally optimized for bi directional traffic and ACK packets are frequently delayed while waiting for data packets on which they can piggy back. Given that ACKs must be sent, their may be little network savings in not terminating the response and issuing a new request.
  • A server may consume more resources once a response stream has been initiated.

Despite these limitations, streaming response techniques are in widespread use and mostly work. However they may be an unsuitable basis for a standard mechanism.

The alternative to streaming responses, is for the server to always send complete responses to any poll. The client will immediately issue a new poll request when a previous poll completes. This is completely legal HTTP and will work over all legal proxies and infrastructure. The limitation of this is that there can be some a small latency penalty if an events occur in short succession as subsequent events must wait for the next poll request.

The question is should/can both techniques be supported?

Addressing

Content

JSON 
blah blah
XML 
blah blah
Multipart MIME 
blah blah cool because structure is very similar to raw HTTP request with headers and content. Can multiplex multiple mime types. Can fall back to normal HTTP if no need to multiplex

Security

User awareness

  • Many Users are not used to browsers acting on there own.
  • Some Users are concerned about "phone home" style applications and would be cautious about an applications that stays in contact with a server and can send information about the users actions without any indication to the user.
  • Browsers that stay in contact with a server may hold open a connection that was intended to time out and/or generate large ISP bills.
  • For sites that dynamically update, it is often impossible to tell the difference between no events and the transport has ceased to function.
  • Best practise for Ajax applications that contact the server without user interaction would be to include a visual indication of this to the user and offer the option to disconnect and reconnect to the server.

Think waving windows icon or spinning firefox balls. This could be a valuable branding tool as well as a useful visual indication to the user.

Proposal(s)

To include minimal messaging in OAA Hub

  • Small client side library:
    • multiplexed messaging
    • XmlHttpRequest like interface
    • Meta data headers plus arbitrary mime type content
  • Wire protocol defined, but:
    • No server side component provided
    • Fall back for non shared messaging should not require any server side component

Coach_Wei's_comments_on_November_9_2006

Greg_Wilkins_communication_proposal

Personal tools