How does the live, real-time typing work in Google

问题:

I'm sure Wave doesn't poll the server every millisecond to find out if the other user has typed something... so how can I see what the other person is typing as they type? And without hogging the bandwidth.

回答1:

Persistent HTTP, Comet

Keep your HTTP connection alive and send characters as they are typed

*Edit in 2014: also, take a look at WebSocket and HTTP/1.1 Upgrade header. Browsers started implementing this around 2010, so I'm adding this to original answer.

回答2:

They probably use Web Sockets, aka server-sent events: http://www.w3.org/TR/websockets The underlying protocol can be found (as a draft) at the IETF.

Update: it doesn't seem WebSockets has any implementation yet; and a video from Google I/O (go to 11:00) talks about a long lived HTTP GET request.

回答3:

Server Push in GWT

Server push is the Wait, Respond, Close, Re-Open paradigm:

• Wait: When the GWT code makes a call to your server for some data that you don't have yet, freeze (wait)

• Respond: Once the requested data is
  available, respond with it

• Close: Then, close the connection.

• Re-Open: Once your GWT code receives the response, immediately open up a new connection to query for the next event.

回答4:

See Video Google Wave: Powered by GWT around at minute 55 (near the end)

Q: How you implement the persistent Connections, the long living http connections

A: Future Plan: HTML5 Web Sockets. Longer term. That's what we use at the moment.

Q: Is there a platform or library for this we can download and play with?

A: Not sure. Don't think so

P.S.: That's what he said. To me it did not make much sense ("future plans" vs "using at the moment"). Any native english speaker might want to verify if I transcribed it correctly?

回答5:

Pure speculation but could it be using the Server Side DOM events from the HTML 5 spec?

回答6:

the entire reason for WebSockets is to have the browser keep a bi-directional socket open to a server so that real time communications can be used. When someone types on the other end, in a wave client, it triggers an event that is sent to the server and the server in turn looks to see who should also receive the event and pass them the event, in this case the typed letter.

WebSocket and Comet are different.

Granville

回答7:

Probably comet for now websocket in the future. Because it works in Firefox 3.5 and from what I've read the websocket is only available in the nightly builds of FF... I could be wrong though... as it appears to not work in IE at all.

回答8:

I spent some time reverse-engineering the Google Wave client code (shameless plug for http://antimatter15.com/misc/read/ which is a read-only public client for google wave for all public waves without need of robots or gadgets which was a lot more useful a month ago when Google didn't launch the upgrades).

Anyway, Google uses the GWT framework with certain aspects of the Google Closure library (which is actually open source and documented) and they use the goog.net.BrowserChannel library, which from the comments is also used for chat functionality within gmail.

http://closure-library.googlecode.com/svn/docs/closure_goog_net_browserchannel.js.html

回答9:

I would assume that they use ajax requests. Do an XMLHttpRequest, which is asynchronous, and when the server has something to send your browser the javascript callback that was registered gets the data and does whatever with it. So basically the browser requests the next event, handles it, repeats indefinitely.