My guess (and this is just a guess) is that Google uses the PUSH service. This seems like the most viable option, given that their chat client (which is also integrated into the window) also uses this to deliver real-time messages with minimal delay.
I am sure that they have a whole installation that controls the entire connection connected and sending flags to trigger certain elements. You will not see connection triggers, because the initial page of visits establishes a connection, and then simply freezes during the whole time that you open on the page. eg.
- You are viewing a page
- The browser has established a connection with [example] api.docs.google.com [/ example] and remains open.
- The client code then sends various commands and receives a selection of responses.
- These commands are sent back and forth while you:
- Lose the connection (timeout, etc.), in which case it will be restored
- Browser window closes
An example, as I see it, a typical message:
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 says I need data. The server responds with the appropriate DOC_CONTENT <docname> <length> <contents> . Then the client runs DOC_AUTOSAVE <docname> <length> <content> . Given the number of potential concurrent requests, I would argue that they retain the "context" in the requests / responses, so after something is sent, it can be matched. In this example, he knows that IM_OK corresponds to the second request ( IM ), and AUTOSAVE_OK corresponds to the first request ( AUTOSAVE ) - something like how the AOL IM protocol works.
Again, this is just an assumption .
-
To prove this, use something like ethereal and see if you can see the information being sent in the background.
Brad christie
source share