websocket - trabajar - ¿Qué tecnología utiliza Google Drive para obtener actualizaciones en tiempo real?

editar simultaneamente google drive

Question

¿Qué tecnología utiliza Google Drive para hacer en tiempo real?

Cuando escribo un documento de Google Drive al que acceden varios usuarios, la pestaña de la Red de herramientas para desarrolladores de Chrome muestra que no hay WebSockets.

Veo que los dos tipos más frecuentes de llamada AJAX tienen "enlazar?" o "guardar?" en la URL. "¿salvar?" Las solicitudes POST se realizan cada vez que escribo, lo que hace que AJAX tenga sentido para enviar actualizaciones al servidor.

Cuando otro usuario escribe, el "enlace?" Más reciente La llamada GET permanece abierta, y la cantidad de datos transferidos a través de esa conexión aumenta. Periódicamente, los "enlaces" se cierran y se abren nuevos, y la lógica parece ser una función de la duración y el tamaño de los datos.

Esto no es un sondeo largo, ya que cuando el servidor envía actualizaciones no completa la respuesta.

Esto no parece ser eventos enviados por el servidor, ya que el tipo de contenido es "text / plain" en lugar de "text / stream".

¿Hay un nombre para lo que Google está haciendo? Si es así, ¿cómo puedo intentar implementar esto?

Answer 1

¿Hay un nombre para la solución de Google para actualizaciones en tiempo real en Drive (como "sondeo largo" o "sockets")?

No tenía nombre hasta ahora. Lo llamaré "sin sondeo" para contrastar con el sondeo y el sondeo largo.

Con el sondeo, el cliente envía periódicamente consultas para nuevos datos.

Con un sondeo largo, el cliente consulta los datos y el servidor retiene la solicitud, finalizando la respuesta con las actualizaciones cuando hay actualizaciones.

Sin sondeo (lo que hace Google Drive) aprovecha la forma en que el navegador puede leer los datos del cuerpo de una solicitud antes de que se complete. Por lo tanto, a medida que los colaboradores escriben y editan más, el servidor agrega más datos a la solicitud actual. Si se cumplen ciertos límites (longitud del contenido o duración de la solicitud), la solicitud se completa y el cliente inicia una nueva solicitud con el servidor.

¿Cómo puedo intentar implementar esto?

Para que el cliente envíe actualizaciones al servidor: esto se puede hacer con POST normales.

Para que el cliente se suscriba a las actualizaciones del servidor:

• El cliente envía un GET para una secuencia de actualización, luego comienza a leer el cuerpo de la respuesta antes de que se complete la respuesta.

  Los objetos XHR pueden emitir eventos de progress antes de que se complete la solicitud. La respuesta (parcial) es accesible usando xhr.responseText . No hay una forma sencilla de ver el progreso con fetch yet (a partir de mayo de 2016).

• El cliente debe iniciar una nueva solicitud cuando finalice la solicitud actual.

El servidor tiene que:

• Mantenga un registro de los clientes que están suscritos a los flujos de actualización.
• Cuando llega una solicitud para un flujo de actualización en particular, escriba los datos en la respuesta, pero no complete la respuesta hasta que la cantidad de datos sea grande o se cumpla un tiempo de espera.

Sin voto, en mi opinión, a pesar de que no he jugado mucho, me parece que es superior a las encuestas largas. El sondeo largo obliga a una compensación entre la latencia y el tamaño del mensaje (dada una tasa constante de actualizaciones), no es necesario realizar un intercambio sin votación. Otra desventaja del sondeo largo es que puede llevar a muchas solicitudes HTTP, pagando la sobrecarga de HTTP cada vez.

La gran ventaja de No-polling sobre WebSockets es que no todos los navegadores admiten el sondeo, aunque el soporte WebSocket es bastante bueno: IE10+ .