Further improvement of the update time?

[billy]

First of all, thanks for the great work.

the video on youtube detailed explained the elegance of the system. It
is really inspirational for understanding the source code.

In the video, fraser said that since the web server cannot touch the
client in real time so the client had to do some sort of polling with
incremental interval to collect others update.

What if we are running on a platform which allow long polling/comet
where the server can touch the client in real time and don't need to
wait for the polling to bring the update of other client?
(then the client would need the shadow backup)

App engine blog said they would support channel api which support some
kind of comet structure
http://code.google.com/intl/zh-TW/events/io/2010/sessions/building-real-time-apps-app-engine-feed-api.html

Although google wave api and etherpad sourcecode seem to provide
similar function, but they are too complicate and overkill for my
application, I only want a realtime collaberative text-area with color
author background. (no annotation needed yet)

[Neil Fraser]

On 28 September 2010 08:03, billy <laibil...@gmail.com> wrote:
> What if we are running on a platform which allow long polling/comet
> where the server can touch the client in real time and don't need to
> wait for the polling to bring the update of other client?
> (then the client would need the shadow backup)
>
> App engine blog said they would support channel api which support some
> kind of comet structure
> http://code.google.com/intl/zh-TW/events/io/2010/sessions/building-real-time-apps-app-engine-feed-api.html

You read my mind. Although I could muscle my way into the "Channel
API" beta, I'd prefer to wait until it is publicly launched and stable
before overhauling MobWrite to take advantage of this mechanism.
Otherwise comet would work on the mobwrite3.appspot.com instance but
fail for everyone else.

In terms of adapting the algorithm, the most straight forward approach
would be to modify the client to sync once a second and modify the
server to hold onto the connection for up to 30 seconds if there is no
server-to-client message to be sent. The client would also be
modified to timeout after two seconds if there is another local
change, and 45 seconds if there isn't. This would result in one
connection per message (as currently implemented), but the latency for
server-to-client messages would drop to under a second since there
would always be a stalled connection waiting to take it. The existing
packet-loss mechanisms would handle all the timed out connections.

Not only would this reduce latency, but it would also reduce the
workload on the server. Once the Channel API is released, this will
become the top priority for MobWrite.

--
Neil Fraser, Programmer & Wizard
http://neil.fraser.name