Ver Mensaje Individual
  #3 (permalink)  
Antiguo 16/11/2011, 09:56
lgruz
 
Fecha de Ingreso: noviembre-2007
Mensajes: 23
Antigüedad: 16 años, 4 meses
Puntos: 4
Respuesta: Comunicación Cliente-Servidor correcta

Cita:
Iniciado por maycolalvarez Ver Mensaje
1 - Ajax longpolling no consiste en enviar n peticiones x segundo, estás errado: el longpolling consiste en que el cliente envía una petición ajax y el server la mantiene abierta hasta un nuevo evento, obviamente cuando el server contesta se cumple el ciclo HTTP y se cierra la conexión, es allí donde el cliente vuelve a establecer otra petición AJAX, ¿ventajas?: que se reduce considerablemente el ancho de banda al mantener una conexión activa por más tiempo que es mejor que enviar n peticiones cada segundo, es una técnica muy utilizada por chats y se ha comprobado que es eficiente, sin embargo puede llegar a consumir mucho del servidor.
Posiblemente este equivocado con este tema ya que son muchas las versiones que me he encontrado. Efectivamente, tu versión según la teoría debería ser así, pero no lo es en la práctica. Utilizando la técnica de Long-Polling de Dojo, por ejemplo, se establece un intervalo de tiempo, en en el cada "X" segundos realiza la petición de "Y" datos. Si comprobamos las trazas de red, veremos que cada "X" segundos se ha vuelto a solicitar el fichero o información determinados. Por ello, para los chats actuales se utilizan otras tecnologías de Push del servidor.


Cita:
Iniciado por maycolalvarez Ver Mensaje
2 - "el servidor no estará siempre encendido": entonces No es un servidor, además un servidor bien configurado puede reiniciarse a consecuencia de fallas de energía, con respecto a node.js puedes hacer que se ejecute automáticamente al iniciar el OS, además de que existen muchas técnicas para prevenciones de caídas de servicios como virtualización, balance de carga o dispositivos para servidores de alta disponibilidad; así que usar WebSockets sólo dependería de la compatibilidad del cliente, porque el escenario del servidor lo puedes controlar tú.
No se trata de una aplicación/web para el público general, sino para un uso privado en empresas. Es por ello que no se cuenta con un servidor al que se conectan los clientes, sino que el propio servidor hace de cliente. Esto me hace querer evitar al máximo todo lo que haya que tocar del servidor, ya que estamos hablando de preparar mucha cantidad de servidores funcionales lo más rápido posible, y que serán manipulados a diario por personas ajenas. El equipo, a ojos del cliente, debe ser un equipo normal, con sus programitas y sus historias.