[html5] r3737 - [e] (0) Update intro to WebSocket protocol.

[whatwg at whatwg.org]

Author: ianh
Date: 2009-09-03 04:15:57 -0700 (Thu, 03 Sep 2009)
New Revision: 3737

Modified:
   index
   source
Log:
[e] (0) Update intro to WebSocket protocol.

Modified: index
===================================================================
--- index	2009-09-03 10:39:29 UTC (rev 3736)
+++ index	2009-09-03 11:15:57 UTC (rev 3737)
@@ -74428,6 +74428,7 @@
   Geoffrey Sneddon,
   George Lund,
   Giovanni Campagna,
+  Graham Klyne,
   Greg Botten,
   Greg Houston,
   Gregg Tavares,

Modified: source
===================================================================
--- source	2009-09-03 10:39:29 UTC (rev 3736)
+++ source	2009-09-03 11:15:57 UTC (rev 3737)
@@ -71453,8 +71453,90 @@
 
   <h5>Introduction</h5>
 
+  <h6>Background</h6>
+
   <p><i>This section is non-normative.</i></p>
 
+  <p>Historically, creating an instant messenger chat client as a Web
+  application has required an abuse of HTTP to poll the server for
+  updates while sending upstream notifications as distinct HTTP
+  calls.</p>
+
+  <p>This results in a variety of problems:</p>
+
+  <ul>
+
+   <li>The server is forced to use a number of different underlying
+   TCP connections for each client: one for sending information to the
+   client, and a new one for each incoming message.</li>
+
+   <li>The wire protocol has a high overhead, with each
+   client-to-server message having an HTTP header.</li>
+
+   <li>The client-side script is forced to maintain a mapping from the
+   outgoing connections to the incoming connection to track
+   replies.</li>
+
+  </ul>
+
+  <p>A simpler solution would be to use a single TCP connection for
+  traffic in both directions. This is what the Web Socket protocol
+  provides. Combined with the Web Socket API, it provides an
+  alternative to HTTP polling for two-way communication from a Web
+  page to a remote server. <a href="#refsWSAPI">[WSAPI]</a></p>
+
+  <p>The same technique can be used for a variety of Web applications:
+  games, stock tickers, multiuser applications with simultaneous
+  editing, user interfaces exposing server-side services in real time,
+  etc.</p>
+
+
+
+  <h6>Protocol overview</h6>
+
+  <p><i>This section is non-normative.</i></p>
+
+  <p>The protocol has two parts: a handshake, and then the data
+  transfer.</p>
+
+  <p>The handshake from the client looks as follows:</p>
+
+  <pre>GET /demo HTTP/1.1
+Upgrade: WebSocket
+Connection: Upgrade
+Host: example.com
+Origin: http://example.com
+WebSocket-Protocol: sample</pre>
+
+  <p>The handshake from the server looks as follows:</p>
+
+  <pre>HTTP/1.1 101 Web Socket Protocol Handshake
+Upgrade: WebSocket
+Connection: Upgrade
+WebSocket-Origin: http://example.com
+WebSocket-Location: ws://example.com/demo
+WebSocket-Protocol: sample</pre>
+
+  <p>Once the client and server have both sent their handshakes, and
+  if the handshake was successful, then the data transfer part
+  starts. This is a two-way communication channel where each side can,
+  independently from the other, send data at will.</p>
+
+  <p>Data is sent in the form of UTF-8 text. Each frame of data starts
+  with a 0x00 byte and ends with a 0xFF byte, with the UTF-8 text in
+  between.</p>
+
+  <p>The Web Socket protocol uses this framing so that specifications
+  that use the Web Socket protocol can expose such connections using
+  an event-based mechanism instead of requiring users of those
+  specifications to implement buffering and piecing together of
+  messages manually.</p>
+
+
+  <h6>Design philosophy</h6>
+
+  <p><i>This section is non-normative.</i></p>
+
   <p>The Web Socket protocol is designed on the principle that there
   should be minimal framing (the only framing that exists is to make
   the protocol frame-based instead of stream-based, and to support a
@@ -71530,50 +71612,9 @@
   HTTP servers is probably easier to manage.</p>
 
 
-  <h6>The Web Socket protocol</h6>
 
-  <p><i>This section is non-normative.</i></p>
 
-  <p>The protocol has two parts: a handshake, and then the data
-  transfer.</p>
 
-  <p>The handshake from the client looks as follows:</p>
-
-  <pre>GET /demo HTTP/1.1
-Upgrade: WebSocket
-Connection: Upgrade
-Host: example.com
-Origin: http://example.com
-WebSocket-Protocol: sample</pre>
-
-  <p>The handshake from the server looks as follows:</p>
-
-  <pre>HTTP/1.1 101 Web Socket Protocol Handshake
-Upgrade: WebSocket
-Connection: Upgrade
-WebSocket-Origin: http://example.com
-WebSocket-Location: ws://example.com/demo
-WebSocket-Protocol: sample</pre>
-
-  <p>Once the client and server have both sent their handshakes, and
-  if the handshake was successful, then the data transfer part
-  starts. This is a two-way communication channel where each side can,
-  independently from the other, send data at will.</p>
-
-  <p>Data is sent in the form of UTF-8 text. Each frame of data starts
-  with a 0x00 byte and ends with a 0xFF byte, with the UTF-8 text in
-  between.</p>
-
-  <p>The Web Socket protocol uses this framing so that specifications
-  that use the Web Socket protocol can expose such connections using
-  an event-based mechanism instead of requiring users of those
-  specifications to implement buffering and piecing together of
-  messages manually.</p>
-
-
-
-
-
   <!--BOILERPLATE middle-ietf-conformance-->
 
   <h6>Terminology</h6>
@@ -88373,6 +88414,7 @@
   Geoffrey Sneddon,
   George Lund,
   Giovanni Campagna,
+  Graham Klyne,
   Greg Botten,
   Greg Houston,
   Gregg Tavares,