Altenwald Blog
Blog sobre programación, software libre, redes, servidores, ...
Menú
Acerca de... ¿Quiénes somos? RSS
Categorías
sistemas (70) desarrollo (128) historias (25) productividad (49) seguridad (10) libros (25) noticias (45) opinión (35) humor (3)
Etiquetas
programación (111) desarrollo de software (79) erlang (75) opinión (37) noticia (36) libros (28) servidores (26) desarrollo web (24) base de datos (24) administración de sistemas (23) php (22) desarrollo ágil (22) empresa (21) otp (20) ruby (19) ingeniería de negocio (18) elixir (18) desarrollo profesional (16) redes (16) seguridad (14)
2009-12-29
1 min desarrollo
Comet ha muerto, ¡larga vida a websockets!
[ programación ]  [ desarrollo web ]  [ erlang ] 

Leyendo el artículo de Joe Armstrong, sobre este mismo título, comenta que con la aparición de websockets (una nueva característica que ha aparecido en HTML5), el sistema comet y otros derivados, están abocados a la extinción.

Desde siempre, el sistema HTTP, llamado también web, ha sido un sistema cliente-servidor, donde el cliente siempre ha sido el navegador web, o cualquier herramienta que pudiese hacer una petición HTTP hacia un servidor, y el servidor, un ente pasivo, se encargaba de procesar la petición y retornar una respuesta. Nada más.

Una de las implementaciones más usadas por este sistema se produce gracias a la característica de HTTP 1.1 de mantener viva la conexión (keep alive) permitiendo al navegador realizar más peticiones y al servidor encauzar una respuesta progresiva, como una lluvia de estrellas (cometas) es el streaming, ya que el sistema puede enviar datos de vídeo progresivamente.

El problema viene dado, también, por la propia especificación de HTTP 1.1, donde se indica que sólo puede haber dos conexiones simultáneas con entre navegador y servidor, con lo que, el uso en una página web con hoja de estilos y bastantes imágenes puede no ser muy aconsejable.

¿Qué aporta de nuevo o de mejorado websockets? a través de HTML y JavaScript de forma simple, se establece una conexión con el servidor dada una URL y un sub-protocolo en el que deben de hablar. Una vez conectado, los elementos html pueden tener eventos del tipo: onopen, onmessage, onclose; indicando los tres eventos que pueden darse en la conexión y el diálogo abierto con el servidor.

Hay que recordar que la interacción vendrá dada por el servidor, esto es que, un programa ejecutándose en el servidor (que no tiene porqué ser de tipo web) puede enviar un evento al puerto especificado por el cliente y el mensaje ser recogido por el navegador y dárselo al elemento al que haga referencia el propio mensaje.

De momento, en Google Chrome se encuentra operativo y se puede probar. En el artículo de Joe Armstrong se puede descargar un código en Erlang para el servidor y un código HTML para el navegador.

Realizaré pruebas y ya comentaré la impresión que me cause el sistema.

Autor
Manuel Rubio
Programación Concurrente & Erlanger