usado toda especie de técnicas para hacer frente al problema de comunicación en tiempo real entre navegadores y servidores web. La web se ha construido alrededor del paradigma de HTTP llamado request/response. Un cliente carga una web y nada ocurre hasta que hace click en algún link. Alrededor de 2005 aparece AJAX (Asynchronous JavaScript And XML), permitiendo una comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas y hacer que parezcan más dinámicas. Aun así la comunicación siempre es iniciada por el cliente, la cual requiere de la interacción del usuario, o de un polling periódico para solicitar nuevos datos al servidor. Desde hace tiempo han existido distintas tecnologías para permitir al servidor enviar datos al cliente cuando estos estuviesen disponibles (Push, Comet, Flash sockets, XHR multipart, htmlfiles). De todas formas, todos estos métodos comparten el mismo problema: generan mucho overhead (se envía mucha información en las cabeceras HTTP), el cual no es muy conveniente para aplicaciones en las que se necesite tener una latencia baja.
*0 /,40"/ ".2"01 ".2"01 ".2"01+ "0-,+0" "0-,+0" "0-,+0"+ setInterval(function(){ $.ajax({url:'/data',success:function(data){ // do something }}); },500); Con polling, el navegador envía una petición http al servidor, e inmediatamente recibe una respuesta. Está técnica supuso el primer intento para los navegadores para ofrecer información en “tiempo real”. Obviamente es una buena técnica si se sabe con exactitud cuándo va a ocurrir un evento y solicitarlo cuando el dato esté disponible, pero en general la obtención de los datos en tiempo real no es muy predecible, con lo que al final se generan muchas peticiones innecesarias, y muchas de ellas pueden que no traigan de vuelta ningún dato porque el servidor no lo tenía disponible. Long-polling, el navegador envía una petición al servidor y el servidor mantiene la conexión abierta durante un período de tiempo. Si se recibe una notificación en ese período de tiempo, se envía una respuesta al cliente con la información, y si no, el servidor cierra la conexión con el cliente. Es importante tener en cuenta que cuando existe un alto volumen de mensajes, long-polling no ofrece una mejora sustancial frente al polling.!De hecho puede ser incluso peor, puede provocar que muchas peticiones se queden en la cola pendientes de resolver.
el cual define un canal de comunicación full-duplex entre cliente y servidor usando un único socket (antes se simulaba la bidireccionalidad usando dos canales distintos, uno para subida y otro para bajada). HTML5 WebSockets no es solamente una mejora gradual sobre las comunicaciones HTTP; representa un avance muy grande, especialmente en aplicaciones de tiempo real, u orientadas a eventos. Logo HTML5: http://www.w3.org/html/logo/
WebSockets fueron desarrollados por Ian Hickson (http://en.wikipedia.org/wiki/Ian_Hickson) como medio para controlar desde un navegador web su maqueta de tren digital. De todas formas es tan sólo una leyenda, ya que Hickson desmintió que ello fuese así : “I think work on Web Sockets (TCPConnection at the time) predates my thoughts of running my train layout using Web Sockets, but Web Sockets definitely would make doing so much easier. The problem is the normal Web app controlling a single system problem: there is one computer with a serial port connection to the Märklin Interface unit, and one wants to be able to write a Web page that communicates with that computer, sending instructions and receiving updates, without having to poll, have multiple connections, use <script> streams in <iframe>s, etc.”
GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Handshake from the server: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat RFC 6455 define el estándar final del protocolo WebSocket. Si bien la API DOM no tiene porque sufrir cambios en su definición, el protocolo sí puede estar sometido a cambios.
Throughput de la red (871 x 1.000) = 871.000 bytes = 6.968.000 bps (6,6 Mbps) • Caso B: 10,000 clientes haciendo polling cada segundo: Throughput de la red (871 x 10.000) = 8.710.000 bytes = 69.680.000 bps (66 Mbps) • Caso C: 100,000 clientes haciendo polling cada 1 segundo: Throughput de la red (871 x 100.000) = 87.100.000 bytes = 696.800.000 bps (665 Mbps) WebSocket: • Use case A: 1,000 clientes reciben 1 mensaje por segundo: Throughput de la red (2 x 1.000) = 2.000 bytes = 16,000 bps (0,015 Mbps) • Use case B: 10,000 clientes reciben 1 mensaje por segundo: Throughput de la red (2 x 10.000) = 20.000 bytes = 160.000 bps (0,153 Mbps) • Use case C: 100,000 clientes reciben 1 mensaje por segundo: Throughput de la red (2 x 100.000) = 200.000 bytes = 1.600.000 bps (1,526 Mbps) ", ("1"+ &#/0
webSocket-Node, WS Java : Jetty Ruby : EventMachine Python : Pywebsocket, Tornado, Twisted Erlang : Shirasu C++ : libwebsockets .NET : SuperWebSocket Si bien NodeJS puede ser mejor al tener una arquitectura orientada a Entrada / salida y por gran rendimiento manejando conexiones concurrentes. Twisted y EventMachine también están orientados a eventos.
para nodeJS: https://github.com/joyent/node/wiki/modules Bases de datos NoSQL MongoDB http://www.mongodb.org/ Redis: http://redis.io/ Comparativa entre varias bases de datos NoSQL: http://kkovacs.eu/cassandra-vs-mongodb-vs- couchdb-vs-redis ,!"