Google 文档自动保存如何工作?

发布于 11-09 19:26 字数 104 浏览 1 评论 0原文

好吧,我知道这听起来很普通。但我指的是 AJAX 级别。我尝试过使用 Firebug 来跟踪 NET 连接和帖子,但这是一个谜。有谁知道他们如何在不破坏网络/浏览器的情况下不断进行即时自动保存?

Okay, I know it sounds generic. But I mean on an AJAX level. I've tried using Firebug to track the NET connections and posts and it's a mystery. Does anyone know how they do the instant autosave constantly without DESTROYING the network / browser?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

澜川若宁2024-11-16 19:26:12

我的猜测(这只是一个猜测)是谷歌使用推送服务。这似乎是最可行的选择,因为他们的聊天客户端(也集成在窗口内)也使用它来以最小的延迟传递“实时”消息。

我敢打赌他们有一个完整的设置来管理所有与连接相关的内容并发送标志来触发特定元素。您不会看到连接触发器,因为初始页面访问建立了连接,然后在页面打开的整个持续时间内挂起。例如

  1. 您访问该页面
    • 浏览器与 [example]api.docs.google.com[/example] 建立了连接并保持打开状态
  2. 然后,客户端代码发送各种命令并接收各种响应。
  3. 这些命令会来回发送,直到您:
    • 失去连接(超时等),在这种情况下会重新建立
    • 浏览器窗口已关闭

我所看到的典型通信示例:

SERVER:                              CLIENT:
-------                              -------
                                     DOC_FETCH mydocument.doc
DOC_CONTENT mydocument.doc 15616 ...      
                                     DOC_AUTOSAVE mydocument.doc 24335 ...
                                     IM collaboratorName Hi Joe!
IM_OK collaboratorName OK
AUTOSAVE_OK mydocument.doc OK

其中 DOC_FETCH 命令表示“我”想要数据。服务器回复相应的DOC_CONTENT<长度> <内容>。然后客户端触发DOC_AUTOSAVE; <长度> <内容>。考虑到潜在的同时请求的数量,我敢打赌他们会在请求/响应中保留“上下文”,以便在发送某些内容后可以将其匹配。在此示例中,它知道 IM_OK 与第二个请求 (IM) 匹配,并且 AUTOSAVE_OK 与第一个请求 (AUTOSAVE< /code>)--类似于 AOL 的 IM 协议的工作原理。

再说一次,这只是一个猜测

--

为了证明这一点,使用 ethereal 之类的东西,看看是否可以看到后台传输的信息。

My guess (and this is only a guess) is that google uses a PUSH service. This seems like the most viable option given their chat client (which is also integrated within the window) also uses this to delivery "real time" messages with minimal latency.

I'm betting they have a whole setup that manages everything connection related and send flags to trigger specific elements. You won't see connection trigers because the initial page visit establishes the connection then just hangs on the entire duration you have the page open. e.g.

  1. You visit the page
    • The browser established a connection to [example]api.docs.google.com[/example] and remains open
  2. The client-side code then sends various commands and receives an assortment of responses.
  3. These commands are sent back and forth until you either:
    • Lose the connection (timeout, etc.) in which case it's re-established
    • The browser window is closed

Example of, how I see, a typical communication:

SERVER:                              CLIENT:
-------                              -------
                                     DOC_FETCH mydocument.doc
DOC_CONTENT mydocument.doc 15616 ...      
                                     DOC_AUTOSAVE mydocument.doc 24335 ...
                                     IM collaboratorName Hi Joe!
IM_OK collaboratorName OK
AUTOSAVE_OK mydocument.doc OK

Where the DOC_FETCH command is saying I want the data. The server replies with the corresponding DOC_CONTENT <docname> <length> <contents>. Then the client triggers DOC_AUTOSAVE <docname> <length> <content>. Given the number of potential simultaneous requests, I would bet they keep the "context" in the requests/responses so after something is sent it can be matched up. In this example, it knows the IM_OK matches the second request (IM), and the AUTOSAVE_OK matches the first request (AUTOSAVE)--Something like how AOL's IM protocol works.

Again, this is only a guess.

--

To prove this, use something like ethereal and see if you can see the information transferring in the background.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文