Introduccion SignalR
•Descargar como PPTX, PDF•
1 recomendación•684 vistas
Charla en la UC de introduccion a SignalR el 11 de marzo de 2015
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (11)
Similar a Introduccion SignalR
Similar a Introduccion SignalR (20)
Último
Último (7)
Introduccion SignalR
- 1. Introducción a SignalR Diego Juez Lasarte /in/diegojuez @Diego_juez Informática en Acción
- 2. ¿Que es SignalR? 1. Librería para desarrolladores ASP.NET que hace el desarrollo de funcionalidad en tiempo real fácil. 2. SignalR permite la comunicación bidireccional entre el servidor y el cliente 3. Ahora el servidor puede hacer “push” del contenido en cuanto esta disponible 4. Soporta WebSockets y se apoya en otras técnicas para dar soporte a viejos navegadores
- 3. ¿Para que SignalR? Mezclar internet, asincronía, y múltiples usuarios colaborando e interactuando al mismo tiempo Se puede usar para añadir cualquier tipo de funcionalidad web en tiempo real Google Docs: si estamos editando un documento online y otro usuario accede al mismo, podemos ver sobre la marcha que ha entrado, e incluso las modificaciones que va realizando sobre el documento.
- 4. Pero se peude usar para muchas mas cosas: • Dashboards y aplicaciones de monitorizacion • Actualizaciones de progreso de un proceso • … Chat Facebook: pareciendo los mensajes tecleados por nuestros compañeros de sala como por arte de magia.
- 5. Ambos sistemas utilizan el mismo tipo de solución: el envío asíncrono de datos entre servidor y clientes en tiempo real.
- 7. POOLING
- 9. LONG POOLING • Más limpio y eficiente • Utiliza HTTP estándar: Válido para todo tipo de agentes de usuario Bastante amigable para proxies, filtros, firewalls
- 11. Dos modelos de comunicación con el cliente: Conexión Persistente y Hubs Conexión Persistente: • Permite acceso a bajo nivel al protocolo de comunicación • Resultara familiar a los usuarios de WCF • Mayor complejidad Hubs: • Conducto de alto nivel sobre el protocolo de comunicación • Permite llamar al cliente y servidor llamar a metodos del otro directamente
- 12. WebSocket es el transporte ideal para SignalR debido a que es el mejor uso hace de la memoria del servidor, tiene la menor latencia y provee mas funcionalidad. Sin embargo sus requirimientos son los mas restrictivos: • El servidor debe ser Windows 2012 o Windows 8 y usar.NET Framework 4.5 Websockets es capaz de crear una conexión con el servidor y mantenerla abierta de forma continua, aunque requiere que esta tecnología esté disponible tanto en el cliente Debido a ello, y para asegurar la máxima compatibilidad con los clientes, la mayoria de las veces se usa Long polling
- 13. Los protocolos de transporte es que pueden ser sustituidos de forma transparente sin afectar a nuestras aplicaciones Nuestros sistemas funcionarán exactamente igual sea cual sea el transporte utilizado, lo que permite que éste sea elegido en cada escenario en función de la disponibilidad de las tecnologías en ambos extremos
- 14. Transportes Son el conjunto de tecnologías utilizadas para mantener crear la conexión continua, o al menos la ilusión de su existencia SignalR es una abstraccion sobre los transportes que son necesarios para hacer comunicacion en tiempo real entre el cliente y el servidor La conexion se inicia como HTTP y se promociona a WebSocket si es posible
- 15. HTML 5 transports WebSocket Server Sent Events Comet transports Forever Frame (Solo para Internet Explorer). Ajax long polling
- 16. Como se selecciona el transporte mas adecuado: 1.Navegador es Internet Explorer 8 or anterior -> Long Polling. 2.Si JSONP esta configurado->, Long Polling. 3.Si es una conexión cross-domain se usara WebSocket si:: •El cliente soporta CORS (Cross-Origin Resource Sharing). •El cliente soporta WebSocket •El servidor soporta WebSocket Si no se cumplen se usara Long Polling 4.Si JSONP no esta configurado y la conexión no es cross-domain se usara WebSocket si cliente y servidor lo soprotan. 5.Si el cliente o el servidor no soportan WebSocket se usara Server Sent Events. 6.Si Server Sent Events no esta disponible, se intentara Forever Frame. 7.Si falla el intento con Forever Frame entonces se usara Long Polling.
- 17. Arquitectura
- 18. SignalR ofrece una visión a muy alto nivel de la comunicación entre el servidor y los múltiples clientes que se encuentren a él conectados Como desarrolladores, trabajaremos sobre una conexión virtualmente siempre abierta
- 19. Implementación de servicios con SignalR • usando “conexiones persistentes” • usando “hubs” más bajo nivel bastante similar a como hacemos utilizando sockets ofrece una abstracción aún mayor
- 20. Entorno web más habitual SERVIDOR: una aplicación ASP.NET CLIENTES: páginas o vistas en las que tendremos un motor de scripting Implementación: SERVIDOR: crear el servicio utilizando las clases del ensamblado SignalR CLIENTE: crear el consumidor del servicio utilizando las clases disponibles en la biblioteca de scripts jQuery.SignalR.js
- 22. • Tenemos un servidor, normalmente IIS… • … sobre el que corre ASP.NET… • … con el que está construido el framework (MVC, Webforms…)… • … en el que desarrollamos nuestras aplicaciones. OWIN (Open Web Interface for .NET)
- 23. • OWIN propone una abstracción que permite separar los servidores y hosts donde se ejecutan las aplicaciones .NET, de las aplicaciones en sí mismas • Una aplicación de servidor escrita con SignalR puede ser alojada con total en: • IIS/ASP.NET, • Un servicio Windows, • Una plataforma basada en Mono/Apache, siempre que existieran los oportunos adaptadores OWIN. • Nuestra aplicación sería la misma, independientemente del entorno en el que se ejecute OWIN (Open Web Interface for .NET)
- 25. Próxima cita: 25 Marzo Introducción a la programación móvil25 multiplataforma con Xamarin con Rafa Serna Más info: http://tresssd.es/inf-acc-2015 Diego Juez Lasarte Informática en Acción /in/diegojuez @Diego_Juez Introducción a SignalR Gracias por rellenar la evaluación
Notas del editor
- Pooling: los cientes están continuamente estableciendo conexiones con el servidor para ver si hay algún nuevo evento a tener en cuenta
- Conexión Persistente: si el servidor tiene algo que enviar a sus clientes, simplemente tendría que transmitirlo por el canal que mantendría abierto con cada uno de ellos
- conexión “pseudopersistente”. El servidor, en lugar de procesar la petición y retornar la respuesta de forma inmediata, espera hasta que haya disponible algún evento o mensaje a enviar al cliente; en este momento, lo retorna como respuesta a la petición original y cierra la conexión. El cliente, por su parte, procesa esta respuesta y realiza inmediatamente después una nueva petición al servidor, que volverá a quedar abierta a la espera de mensajes, y así sucesivamente.
- A Hub is a more high-level pipeline built upon the Connection API that allows your client and server to call methods on each other directly. SignalR handles the dispatching across machine boundaries as if by magic, allowing clients to call methods on the server as easily as local methods, and vice versa. Using the Hubs communication model will be familiar to developers who have used remote invocation APIs such as .NET Remoting. Using a Hub also allows you to pass strongly typed parameters to methods, enabling model binding.
- a pesar de la relativa complejidad que supondría implementar algo así a mano, nosotros no tendremos que hacer nada: SignalR se encarga de llevar a cabo todas estas tareas para ofrecernos la sensación de estar siempre conectados
- WebSocket is the only transport that establishes a true persistent, two-way connection between client and server. However, WebSocket also has the most stringent requirements; it is fully supported only in the latest versions of Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox, and only has a partial implementation in other browsers such as Opera and Safari. Server Sent Events, also known as EventSource (if the browser supports Server Sent Events, which is basically all browsers except Internet Explorer.) Forever Frame creates a hidden IFrame which makes a request to an endpoint on the server that does not complete. The server then continually sends script to the client which is immediately executed, providing a one-way realtime connection from server to client. The connection from client to server uses a separate connection from the server to client connection, and like a standard HTML request, a new connection is created for each piece of data that needs to be sent
- (that is, if the SignalR endpoint is not in the same domain as the hosting page)
- conexión virtualmente siempre abierta: en servidor podremos detectar cuándo se ha conectado un nuevo cliente, cuándo se ha desconectado, recibir mensajes de éstos, enviar mensajes a los clientes conectados…, en definitiva, todo lo que podemos necesitar para crear aplicaciones asíncronas multiusuario manteniendo la conexión de los clientes con el servidor mediante distintos mecanismos denominados “transportes”, que son el conjunto de tecnologías utilizadas para mantener crear la conexión continua, o al menos la ilusión de su existencia
- Host, que es el proceso que aloja el sistema, como podría ser IIS o una aplicación de consola. Server, que se ejecuta en el interior de un Host y que actúa como servidor HTTP. Procesa las peticiones usando la sintaxis y reglas definidas por OWIN. Middleware, que son componentes ejecutados durante la gestión de las peticiones, que tienen la capacidad de capturar, procesar, e incluso alterar el contenido de las solicitudes y las respuestas. Normalmente en una aplicación usaremos varios middlewares, que componen una cadena llamada pipeline, que es “la tubería” por donde pasarán todas las peticiones recibidas. En un pipeline podría existir, por ejemplo, un módulo middleware que registrara en un log todas las peticiones, otro que comprobara si la petición procede de un usuario autenticado, y, al final, un módulo que retorne al usuario un contenido determinado. Pero siempre la información viajaría de la forma en que se describe en la especificación OWIN. Framework, que son los marcos de trabajo sobre los que construiremos nuestras aplicaciones, como podrían ser MVC, Web API o SignalR. Están totalmente desacoplados del Server, pues toda la información que necesita le llegará usando las abstracciones propuestas por OWIN. Application, nuestra aplicación, construida sobre uno de estos frameworks compatibles con OWIN.