ASP.net SignalR 2.0 - José María Aguilar - Krasis Press

Programacin con ASP.Net

SignalR 2.0

Jos Mara Aguilar Esteban

TTULO ORIGINAL: SignalR Programming in Microsoft ASP.NET Traduccin autorizada por Microsoft Corporation de la obra publicada originalmente en lengua inglesa por Microsoft Press en 2014.

PROGRAMACIN CON ASP.NET SIGNALR 2.0

No est permitida la reproduccin total o parcial de este libro, ni su tratamiento informtico, ni la transmisin de ninguna forma o por cualquier medio, ya sea electrnico, mecnico, por fotocopia, por registro u otros mtodos, sin el permiso previo y por escrito de los titulares del Copyright. Dirjase a CEDRO (Centro Espaol de Derechos Reprogrficos, www.cedro.org) si necesita fotocopiar o escanear algn fragmento de esta obra.

DERECHOS RESERVADOS 2015, respecto a la primera edicin en espaol, por Krasis Consulting, S. L.

www.Krasis.com

ISBN: 978-84-941112-6-6

CREATIVIDAD

Diseo cubierta: Pablo Iglesias Francisco y Natalia Matesanz Urea Fruta cubierta: El pltano tiene su origen en Asia meridional, siendo conocido en el Mediterrneo desde el ao 650 d.C. La especie lleg a Canarias en el siglo XV y desde all fue llevado a Amrica en el ao 1516. El cultivo comercial se inicia en Canarias a finales del siglo XIX y principios del siglo XX. En lo que respecta a sus propiedades nutritivas, destaca su

contenido de hidratos de carbono, por lo que su valor calrico es elevado. Los nutrientes ms representativos del pltano son el potasio, el magnesio, el cido flico y sustancias de accin astringente; sin despreciar su elevado aporte de fibra, del tipo fruto-oligosacridos.

Para Inma, mi dulce e inseparable compaera de aventuras.

Te quiero.

Jos M.

Agradecimientos

Aunque suene algo manido, un libro como este no sera posible sin la colaboracin de

muchas personas que han dedicado su tiempo y esfuerzo a hacerlo realidad, y es justo

dedicarles unas palabras de agradecimiento.

En particular, me gustara agradecer su implicacin a mi editor en CampusMVP.es,

Jos Manuel Alarcn (@jm_alarcon), por su habilidad en la gestin del proyecto,

coordinacin, revisiones y sabias recomendaciones que nos han conducido hasta este

punto.

Tambin ha resultado imprescindible la colaboracin de Javier Surez Ruz

(@jsuarezruiz) por sus aportaciones y ejemplos de implementacin de clientes SignalR

en entornos no web como Windows Phone o WinRT.

Por parte de Microsoft, debo agradecer a Devon Musgrave su inters en este proyecto

desde el primer momento, sin el cual el libro nunca hubiese visto la luz.

vii

Contenido

AGRADECIMIENTOS ................................................................................................ V

CONTENIDO ............................................................................................................ VII

PRESENTACIN .................................................................................................... XIII

1.- Quin debera leer este libro ................................................................................................ xiii 1.1.- Requisitos previos ......................................................................................................... xiii 1.2.- Quin NO debera leer este libro ............................................................................ xiv

2.- Esquema del libro ..................................................................................................................... xiv 2.1.- Por dnde empezar a leer este libro ....................................................................... xiv

3.- Convenciones y caractersticas de este libro ..................................................................... xv 4.- Requerimientos del sistema .................................................................................................... xv 5.- Ejemplos de cdigo .................................................................................................................. xvi

5.1.- Instalando los ejemplos de cdigo ............................................................................ xvi 5.2.- Cmo usar los ejemplos de cdigo ......................................................................... xvii 5.3.- Notas sobre esta versin ........................................................................................... xvii

CAPTULO 1: INTRODUCCIN ........................................................................... 19

1.- Internet, asincrona, multiusuario uau! ........................................................................... 19

CAPTULO 2: HTTP: EL CLIENTE ES EL QUE MANDA.................................. 23

1.- Funcionamiento de HTTP ....................................................................................................... 23 2.- Polling, la solucin? .................................................................................................................. 25 3.- Push: la iniciativa es del servidor ........................................................................................... 26

3.1.- WebSockets .................................................................................................................... 28 3.2.- Server-Sent Events (aka API Event Source) ............................................................ 29 3.3.- Push hoy ........................................................................................................................... 31

3.3.1.- Long polling.............................................................................................................. 31 3.3.2.- Forever frame ......................................................................................................... 33

3.4.- El mundo necesita algo ms que Push ...................................................................... 34

viii Programacin con ASP.Net SignalR 2.0

viii

CAPTULO 3: INTRODUCCIN A SIGNALR ..................................................... 37

1.- Presentando a SignalR .............................................................................................................. 37 2.- Qu ofrece SignalR.................................................................................................................... 39 3.- Dos niveles de abstraccin ..................................................................................................... 40 4.- Plataformas soportadas ............................................................................................................ 41 5.- OWIN y Katana, the new kids on the block ...................................................................... 42 6.- Instalacin de SignalR ................................................................................................................ 45

CAPTULO 4: CONEXIONES PERSISTENTES ................................................... 49

1.- Introduccin ................................................................................................................................ 49 2.- Implementacin del lado servidor ......................................................................................... 50

2.1.- Mapeo y configuracin de conexiones persistentes ............................................. 51 2.2.- Eventos de una Persistent Connection .................................................................... 52 2.3.- Envos de mensajes a clientes ..................................................................................... 55 2.4.- Tratamiento asncrono de eventos ........................................................................... 58 2.5.- Grupos de conexiones ................................................................................................. 58 2.6.- La clase de inicializacin OWIN ................................................................................ 60

3.- Implementacin del lado Cliente ........................................................................................... 62 3.1.- Iniciar la conexin usando el cliente JavaScript ...................................................... 62 3.2.- Soporte para navegadores antiguos .......................................................................... 64 3.3.- Soporte para conexiones cross-domain .................................................................. 65 3.4.- Envo de mensajes .......................................................................................................... 67 3.5.- Recepcin de mensajes ................................................................................................ 68 3.6.- Envo de informacin adicional al servidor ............................................................. 69 3.7.- Otros eventos disponibles en cliente ....................................................................... 71

4.- Negociacin de Transporte .................................................................................................... 71 5.- Ajuste de parmetros de configuracin de SignalR .......................................................... 73 6.- Ejemplo completo: tracking de visitantes ............................................................................ 75

6.1.- Creacin del proyecto e instalacin ......................................................................... 76 6.2.- Implementacin del lado cliente ................................................................................ 76

6.2.1.- Marcado HTML ...................................................................................................... 76 6.2.2.- Scripts (Scripts/Tracking.js) ................................................................................. 76

6.3.- Implementacin del lado servidor ............................................................................. 78 6.3.1.- Conexin persistente (TrackerConnection.cs) ............................................. 78 6.3.2.- Startup code (Startup.cs) ..................................................................................... 78

CAPTULO 5: HUBS ................................................................................................. 79

1.- Introduccin ................................................................................................................................ 79 2.- Implementacin del servidor .................................................................................................. 80

2.1.- Configuracin y registro de rutas .............................................................................. 81 2.2.- Creacin de Hubs .......................................................................................................... 82

Contenido ix

2.3.- Recepcin de mensajes ................................................................................................ 82 2.4.- Envo de mensajes a clientes ....................................................................................... 87 2.5.- Envo de mensajes a usuarios especficos ................................................................ 91 2.6.- Mantenimiento de estado ............................................................................................ 92 2.7.- Acceso a informacin del contexto de la peticin ................................................ 94 2.8.- Notificacin de conexiones y desconexiones ........................................................ 95 2.9.- Gestin de grupos ......................................................................................................... 95 2.10.- Mantenimiento de estado en el servidor ......................................................... 96

3.- Implementacin del cliente ................................................................................................... 102 3.1.- Clientes JavaScript ....................................................................................................... 102 3.2.- Generacin del proxy ................................................................................................. 102

3.2.1.- Generacin manual de proxies JavaScript ...................................................... 104 3.3.- Establecimiento de la conexin ................................................................................ 107 3.4.- Envo de mensajes al servidor................................................................................... 110 3.5.- Envo de informacin adicional ................................................................................. 113 3.6.- Recepcin de mensajes enviados desde el servidor ........................................... 114 3.7.- Logging ............................................................................................................................ 115 3.8.- Mantenimiento de estado .......................................................................................... 117 3.9.- Implementacin del cliente sin proxy ..................................................................... 118

3.9.1.- Establecimiento de la conexin......................................................................... 118 3.9.2.- Invocacin de mtodos del servidor ............................................................... 119 3.9.3.- Mantenimiento de estado ................................................................................... 120 3.9.4.- Recepcin de mensajes enviados desde el servidor .................................... 120

4.- Ejemplo completo: pizarra compartida .............................................................................. 121 4.1.- Creacin del proyecto y puesta en marcha .......................................................... 122 4.2.- Implementacin del lado cliente .............................................................................. 122

4.2.1.- Marcado HTML (drawingboard.html) ............................................................. 122 4.2.2.- Scripts (Scripts/DrawingBoard.js) ..................................................................... 122

4.3.- Implementacin del lado servidor ........................................................................... 124 4.3.1.- Hub (DrawingBoard.cs) ...................................................................................... 124 4.3.2.- Startup code (Startup.cs) .................................................................................... 125

CAPTULO 6: CONEXIONES PERSISTENTES Y HUBS DESDE OTROS PROCESOS .............................................................................................................. 127

1.- Acceso desde otros procesos .............................................................................................. 127 2.- Acceso externo usando conexiones persistentes ........................................................... 129 3.- Ejemplo completo: seguimiento de conexiones en el servidor ................................... 130

3.1.- Creacin del proyecto y puesta en marcha .......................................................... 131 3.2.- Implementando un sitio web ..................................................................................... 132

3.2.1.- Marcado de la pgina (default.aspx)................................................................. 132 3.2.2.- Code-behind (default.aspx.cs)........................................................................... 132

3.3.- Sistema de trazado de peticiones (lado servidor) ............................................... 133 3.3.1.- Conexin persistente (ConnectionSpy.cs) .................................................... 133 3.3.2.- Startup code (Startup.cs) ................................................................................... 133 3.3.3.- Clase global de aplicacin (Global.asax.cs) .................................................... 133

x Programacin con ASP.Net SignalR 2.0

x

3.3.4.- Cambios opcionales en la configuracin (web.config) ................................ 135 3.4.- Sistema de trazado de peticiones (lado cliente) .................................................. 135

3.4.1.- Pgina de espionaje (spy.html) .......................................................................... 135 4.- Acceso externo Usando Hubs ............................................................................................. 136 5.- Ejemplo completo: Barra de progreso ............................................................................... 137

5.1.- Creacin del proyecto y puesta en marcha .......................................................... 138 5.2.- Implementacin del lado cliente .............................................................................. 138

5.2.1.- Marcado HTML (progress.html) ...................................................................... 138 5.2.2.- Estilos (Styles/ProgressBar.css) ....................................................................... 138 5.2.3.- Script (Scripts/ProgressBar.js) ........................................................................ 139

5.3.- Implementacin del lado servidor ........................................................................... 140 5.3.1.- Hub .......................................................................................................................... 140 5.3.2.- Proceso costoso (HardProcess.Aspx) ............................................................ 140 5.3.3.- Startup code (startup.cs).................................................................................... 141

CAPTULO 7: APLICACIONES REAL-TIME MULTIPLATAFORMA ............ 143

1.- Signalr en la web y ms all .............................................................................................. 143 2.- Servidores SignalR multiplataforma..................................................................................... 144

2.1.- Hosting de SignalR en aplicaciones no web .......................................................... 144 2.1.1.- Hosting en una aplicacin de consola ............................................................. 145 2.1.2.- SignalR en un servicio Windows ...................................................................... 148

2.2.- Hosting de SignalR en plataformas no Windows................................................. 153 3.- Clientes SignalR multiplataforma ......................................................................................... 155

3.1.- Acceso a servicios desde clientes .NET no web ................................................. 156 3.1.1.- Creacin y apertura de una Conexin Persistente .................................... 156 3.1.2.- Envo y recepcin de datos usando Conexiones Persistentes ................. 159 3.1.3.- Creacin y apertura de conexiones a Hubs ................................................. 161 3.1.4.- Comunicacin con el servidor usando Hubs ................................................ 162 3.1.5.- Logging .................................................................................................................... 165 3.1.6.- Ejemplo: aplicacin de consola ......................................................................... 167 3.1.7.- Ejemplo: aplicacin Windows 8/ Windows 8.1 con C#/XAML ............... 169 3.1.8.- Clientes Windows Phone 8............................................................................... 174

3.2.- Consumo de servicios desde otras plataformas .................................................. 176

CAPTULO 8: DESPLEGANDO Y ESCALANDO SIGNALR ........................... 179

1.- Despliegue de aplicaciones SignalR ..................................................................................... 179 2.- Los problemas del crecimiento ............................................................................................ 181 3.- Escalabilidad en SignalR .......................................................................................................... 184 4.- Escalando sobre backplanes .................................................................................................. 188

4.1.- Service bus de Windows Azure ............................................................................... 188 4.1.1.- Configuracin del servicio ................................................................................. 189 4.1.2.- Activacin del backplane .................................................................................... 191

Contenido xi

4.2.- SQL Server .................................................................................................................... 193 4.2.1.- Configuracin de la base de datos ................................................................... 193 4.2.2.- Activacin del backplane .................................................................................... 195

4.3.- Redis ................................................................................................................................ 196 4.3.1.- Instalacin de Redis ............................................................................................. 196 4.3.2.- Activacin del backplane .................................................................................... 198

5.- Backplanes personalizados .................................................................................................... 199 6.- Mejora de rendimiento en servicios SignalR ..................................................................... 202

6.1.- Configuracin de servidores ..................................................................................... 204 6.2.- Monitorizacin de rendimiento ................................................................................ 205

6.2.1.- Actividad en conexiones .................................................................................... 207 6.2.2.- Errores .................................................................................................................... 208 6.2.3.- Actividad en el bus de mensajera.................................................................... 208 6.2.4.- Bus de proveedores de scaleout ...................................................................... 209 6.2.5.- Otros contadores de rendimiento interesantes .......................................... 210

CAPTULO 9: TEMAS AVANZADOS ................................................................. 211

1.- Autorizacin en SignalR ......................................................................................................... 211 1.1.- Control de acceso en Conexiones Persistentes .................................................. 211 1.2.- Control de acceso en Hubs ...................................................................................... 212 1.3.- Autenticacin del cliente............................................................................................ 215

2.- Un framework extensible ...................................................................................................... 221 3.- Inyeccin de Dependencias ................................................................................................... 227

3.1.- Inyeccin manual de dependencias .......................................................................... 230 3.2.- Liberacin de dependencias ...................................................................................... 231 3.3.- Contenedores de Inversin de Control ................................................................ 232

3.3.1.- SignalR con Unity ................................................................................................. 234 3.3.2.- SignalR con Ninject .............................................................................................. 236

4.- Pruebas unitarias con SignalR ............................................................................................... 237 4.1.- Introduccin muy (pero muy) rpida al unit testing .......................................... 237 4.2.- Unit testing de Hubs ................................................................................................... 243 4.3.- Unit testing de Conexiones Persistentes............................................................... 248

5.- Intercepcin de mensajes en Hubs ..................................................................................... 251 6.- Integracin con otros frameworks ..................................................................................... 255

6.1.- WebAPI .......................................................................................................................... 255 6.2.- ASP.NET MVC .............................................................................................................. 258 6.3.- Knockout ....................................................................................................................... 259 6.4.- AngularJS ........................................................................................................................ 262

NDICE ANALTICO ............................................................................................... 267

xiii

Presentacin

SignalR, la ltima incorporacin al stack de tecnologas de desarrollo para la web de Microsoft, es un marco de trabajo que facilita la creacin de asombrosas aplicaciones

en tiempo real, como pueden ser herramientas de colaboracin online, juegos

multiusuario, o servicios de informacin en vivo, cuyo desarrollo ha sido

tradicionalmente bastante complejo.

Este libro proporciona un recorrido completo sobre desarrollo con SignalR

partiendo desde cero, aunque tambin se tratarn temas relativamente avanzados. La

idea es que al finalizar su lectura el lector conozca las posibilidades de este marco de

trabajo y sea capaz de aplicarlo con xito en la creacin de sistemas realtime de cualquier tamao. Tambin puede ser utilizado como manual de referencia pues,

aunque no de forma exhaustiva, en l se recoge la mayora de caractersticas de

aplicacin prctica durante el desarrollo de sistemas con SignalR, y se proporcionan las

bases para dominarlos en su totalidad.

1.- QUIN DEBERA LEER ESTE LIBRO

El objetivo de este libro es ayudar a los desarrolladores a comprender, conocer y

programar componentes o aplicaciones basadas en SignalR. Puede resultar

especialmente interesante para desarrolladores que necesitan hacer uso de la inmediatez

del tiempo real en aplicaciones existentes o que desean crear nuevos sistemas basados

en este paradigma.

Los desarrolladores especializados en back-end podrn aprender a implementar servicios en tiempo real que podrn ser consumidos desde cualquier cliente, y a cmo

enfrentarse a escenarios como la necesidad de escalabilidad o mejorar la calidad

mediante pruebas unitarias. Aquellos ms orientados al front-end, vern cmo pueden consumir servicios realtime y aadir caractersticas espectaculares a sus creaciones en

el lado cliente. En especial, los desarrolladores web encontrarn una va realmente

sencilla para romper limitaciones propias del mundo basado en HTTP gracias al uso de

push y la asincrona de estas soluciones.

1.1.- Requisitos previos

En este libro asumiremos que el lector dispone de buenos conocimientos en C# y

programacin en el entorno .NET en general. Adems, dado que tanto el propio

SignalR como muchos ejemplos y contenidos estn muy enfocados al mundo web, es

xiv Programacin con ASP.Net SignalR 2.0

necesario conocer los protocolos sobre los que se sustenta, as como tener un cierto

conocimiento de los lenguajes bsicos de estos entornos como HTML y, en particular,

JavaScript.

Aunque no es estrictamente necesario, s sera interesante disponer de algunos

conocimientos sobre desarrollo con jQuery, Windows Phone 8 o WinRT para los

captulos donde se desarrollan ejemplos y contenidos relativos a ellos, y tcnicas tales

como unit testing (pruebas unitarias), mocking o inyeccin de dependencias para los

contenidos finales.

1.2.- Quin NO debera leer este libro

Los lectores que no conozcan la plataforma .NET y C# no podrn sacar partido a las

enseanzas del libro. Si no dispones de conocimientos de JavaScript te resultar

complicado seguir el hilo a todo lo explicado.

2.- ESQUEMA DEL LIBRO

El libro est estructurado en nueve captulos, a travs de los cuales se irn recorriendo

distintos aspectos del desarrollo de sistemas multiusuario en tiempo real con SignalR,

partiendo de cero y hasta llegar a implementar caractersticas avanzadas de este marco

de trabajo.

Los dos primeros captulos son puramente introductorios y sern de utilidad para

entender el contexto tecnolgico y las bases en las que se asienta este nuevo marco de

trabajo.

Afianzados estos aspectos, en el captulo 3 se presentar SignalR a alto nivel,

mostrando su posicin en la pila de tecnologas de desarrollo para la web de Microsoft

y otros conceptos relacionados como OWIN y Katana.

A partir de este punto, empezaremos a entrar en detalle en cmo desarrollar

aplicaciones utilizando SignalR. Los captulos 4 y 5 los dedicaremos a estudiar el

desarrollo desde distintos niveles de abstraccin, usando conexiones persistentes y

hubs. En el captulo 6, estudiaremos cmo integrar estos componentes con otras

tecnologas dentro de la misma aplicacin, y ya en el captulo 7 veremos cmo

implementar clientes multiplataforma.

El captulo 8 lo dedicaremos a mostrar distintos escenarios de despliegue, y las

soluciones de escalado ofrecidas por SignalR. En el captulo 9 encontraremos una

miscelnea en la que trataremos aspectos algo ms avanzados, como la seguridad,

extensibilidad, testing y otros.

2.1.- Por dnde empezar a leer este libro

Aunque el libro est estructurado de forma que puede ser ledo de principio a fin

siguiendo una lnea progresiva de profundizacin en los contenidos tratados, tambin

Presentacin xv

puede ser consultado accediendo directamente a captulos especficos, dependiendo del

nivel de conocimientos de partida y las necesidades concretas del lector.

As, para desarrolladores que se acercan por primera vez a SignalR, la

recomendacin sera leer el libro de principio a fin, en el orden en que han sido escritos

los captulos.

Por otra parte, para aquellos que ya conocen SignalR y han desarrollado con l en

cualquiera de sus versiones, bastar con ojear rpidamente los tres primeros captulos,

y con un poco ms de detenimiento los captulos dedicados al desarrollo con

conexiones persistentes o Hubs para detectar aspectos que no conocan o cambios

respecto a versiones anteriores. A partir de ah, ya sera posible ir directamente a

solucionar las dudas sobre aspectos concretos, como las caractersticas de escalabilidad

del framework, implementar mecanismos de autorizacin, o ver cmo realizar pruebas

unitarias a Hubs.

En cualquier caso, independientemente del captulo o seccin consultada, es

interesante descargar e instalar los proyectos de ejemplo relacionados, que permitirn

practicar y afianzar los conceptos tratados.

3.- CONVENCIONES Y CARACTERSTICAS DE ESTE LIBRO

Este libro presenta la informacin usando convenciones diseadas para que resulte

legible y fcil de seguir:

Elementos recuadrados con la etiqueta Nota incluye informacin adicional

o mtodos alternativos para completar con xitos las tareas.

El texto que debes teclear (adems del que aparece en los cuadros de cdigo)

se muestra en negrita.

El signo (+) entre el nombre de dos teclas significa que debes presionar ambas

teclas a la vez. Por ejemplo, pulsa Alt+Tab quiere decir que debes

mantener pulsada la tecla Alt mientras presionas la tecla Tab.

Una barra vertical entre dos o ms tems (por ejemplo Archivo | Cerrar),

indica que deberas seleccionar primero el men o el tem del men

indicado, luego el siguiente, etc.

4.- REQUERIMIENTOS DEL SISTEMA

Para seguir adecuadamente los ejemplos mostrados en el libro y poder practicar con

ellos, es necesario disponer, como mnimo, de los siguientes elementos hardware y

software:

xvi Programacin con ASP.Net SignalR 2.0

Ordenador equipado con procesador de velocidad superior a 1.6GHz (2 GHz recomendado).

2 GB de RAM (4 GB recomendable).

Tarjeta de vdeo compatible con DirectX 9, capaz de mostrar resoluciones superiores a 1024x768.

Sistema operativo Windows 7 SP1, Windows 8, Windows 8.1. o ediciones de Windows Server superior a la 2008 R2 SP1.

Internet Explorer 10.

Visual Studio 2012 o superior, en cualquiera de sus ediciones. Es posible utilizar versiones Express en la mayora de los casos.

Conexin a internet.

Algunos ejemplos pueden requerir disponer de una cuenta en el sistema con

permisos de administrador, o instalar complementos como el SDK de Windows Phone.

Asimismo, en algunos captulos se utilizan recursos externos como servicios de

Windows Azure.

5.- EJEMPLOS DE CDIGO

A lo largo de este libro se muestran ejemplos, e incluso proyectos completos, para

ilustrar los conceptos tratados. La mayor parte de ellos, as como otros ejemplos

adicionales, pueden ser descargados desde la siguiente direccin:

http://www.campusmvp.es

Sigue las siguientes instrucciones para descargar el fichero:

SignalRPRogramming_codesamples.zip

Nota: Adems de los ejemplos de cdigo, deberas tener instalado en tu

sistema Visual Studio 2012 o 2013

5.1.- Instalando los ejemplos de cdigo

Para instalar los ejemplos de cdigo, simplemente descarga el archivo indicado y

descomprmelo sobre una carpeta de tu sistema.

Presentacin xvii

5.2.- Cmo usar los ejemplos de cdigo

Tras descomprimir el archivo, se habr creado una estructura de carpetas que sigue la

misma organizacin que los captulos del libro comenzando por el captulo cuarto, que

es donde empezaremos a ver ejemplos de cdigo:

Captulo 04 Conexiones persistentes

Captulo 05 Hubs

Captulo 06 Accesos Externos

En el interior de cada una de estas carpetas se encuentra a su vez una subcarpeta por

cada proyecto de ejemplo incluido, numeradas siguiendo el orden en el que los

conceptos son tratados a lo largo del texto del libro:

Captulo 08 Escalado o 1-AzureServiceBus o 2-SqlServer o

Dentro de estas carpetas se puede encontrar el archivo de solucin (*.sln) especfico

para el ejemplo. Las soluciones son totalmente independientes entre s e incluyen un

ejemplo totalmente funcional, listo para ejecutar (F5 desde Visual Studio), aunque en

algunos casos ser necesario realizar algunos ajustes en las configuraciones con

anterioridad. En estos casos, se siempre se detallan instrucciones en la pgina principal

del proyecto, o en un archivo readme.txt.

5.3.- Notas sobre esta versin

Este libro ha sido escrito usando la versin 2.0.0 de SignalR, por lo tanto, a lo largo del

mismo encontrars numerosas referencias a dicha versin.

Sin embargo, el equipo de SignalR en Microsoft, est continuamente esforzndose

por mejorar el producto, de modo que aparecern actualizaciones del software con

cierta frecuencia. La numeracin de las versiones es generalmente del tipo 2.0.x o

2.x.0. Adems de correcciones, dichas versiones podran incluir algunas caractersticas

nuevas y otras mejoradas, pero nunca cambios significativos en el desarrollo de APIs.

En cualquier caso, los contenidos del libro seguirn siendo vlidos una vez

actualizados los componentes a las nuevas versiones. Aunque, obviamente s ser necesario hacer cambios en las referencias existentes en el cdigo fuente de los

ejemplos, especialmente en el caso de referencias a los scripts de las bibliotecas. As,

por ejemplo:

xviii Programacin con ASP.Net SignalR 2.0

una vez instalada la versin 2.0.1 de SignalR, el cdigo debera cambiarse por:

19

CAPTULO

1.- INTERNET, ASINCRONA, MULTIUSUARIO UAU!

Una aplicacin que mezcla internet, asincrona, y mltiples usuarios colaborando e

interactuando al mismo tiempo siempre es merecedora de un uau!. Seguro que en algn momento todo nos hemos quedado maravillados con la interactividad que

presentan algunos sistemas web modernos, como Facebook, Twitter, Gmail, Google

Docs, Office Web Apps, o muchos otros, en las que estamos recibiendo

actualizaciones, prcticamente en tiempo real, sin necesidad de recargar la pgina.

Por ejemplo, en Office Web Apps, 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. O algo ms cotidiano, en un

simple chat va web van apareciendo los mensajes tecleados por nuestros compaeros

de sala como por arte de magia. Ambos sistemas utilizan el mismo tipo de solucin: el

envo asncrono de datos entre servidor y clientes en tiempo real.

Los desarrolladores con experiencia en el mundo web estamos acostumbrados al

tradicional enfoque propuesto por los protocolos que rigen este entorno: el cliente es el

elemento activo, quien realiza las peticiones solicitando informacin, y el servidor se

limita a responderlas. Probablemente por esto, nos causa tanto asombro encontrar

aplicaciones en las que el lado cliente es actualizado directamente por el servidor, por

ejemplo, porque un nuevo usuario ha entrado a editar el documento, o porque el

compaero de sala escribi un mensaje en el chat. Pura magia.

Y sin duda, el mundo est demandando esta inmediatez: los usuarios necesitan

conocer de forma inmediata lo que est ocurriendo en su entorno, en los documentos en

los que estn trabajando, en sus redes sociales, sus juegos en lnea, y, en cada vez ms mbitos de su vida cotidiana. No quieren ir a buscar la informacin como se haca hace

tan solo unos aos, quieren que la informacin llegue a ellos tan pronto como sea

generada.

Introduccin

1

20 Programacin con ASP.Net SignalR 2.0

Esta necesidad ya viene plasmndose a nivel de protocolos de la red desde hace

algn tiempo, puesto que el veterano HTTP, tal y como fue definido en su momento,

no es capaz de cubrirlas de forma eficiente. De hecho, conscientes de ello, tanto los

organismos que definen los estndares y protocolos para la red como los propios

fabricantes de navegadores llevan aos trabajando en nuevas frmulas para comunicar

cliente y servidor en sentido opuesto al habitual, es decir, permitiendo que sea el

servidor el que tome la iniciativa en la comunicacin.

Esto se ha materializado en nuevos protocolos que pueden ser utilizados de forma

relativamente fiable, aunque an estn algo lejos de lo que podramos considerar, a da

de hoy, soluciones de carcter universal. La gran diversidad de plataformas en cliente,

servidor, e incluso en lo relativo a las infraestructuras de red, hacen realmente difcil y

lenta la adopcin de estos nuevos mecanismos. Ms adelante entraremos en mucho

mayor detalle sobre estos aspectos.

Pero no son slo esos los problemas a los que hay que enfrentarse a la hora de

desarrollar aplicaciones multiusuario en tiempo real. Las comunicaciones, como bien

sabemos, son factores inestables e imprevisibles, y esto hace que la gestin y

distribucin de los mensajes a los usuarios sea bastante compleja. Por ejemplo, en una

aplicacin de chat podramos tener en una misma sala usuarios conectados usando

anchos de banda muy distintos, y, adems, este factor podra ir variando a lo largo del

tiempo que dure la sesin de charla. En este escenario, y para evitar que se pierdan

mensajes, el servidor debera ser capaz de almacenarlos temporalmente, enviarlos a sus

destinatarios e ir controlando qu usuarios los han recibido ya, teniendo siempre en

cuenta las condiciones de las comunicaciones con cada uno de ellos, o los posibles

cortes que puedan producirse en la transferencia, reenviando los datos si es preciso. En

cierto sentido, es muy similar a las caractersticas que podemos encontrar en los

tradicionales servidores SMTP, pero con el requisito aadido de la inmediatez

inherente a los sistemas en tiempo real. Seguro que cualquiera de nosotros nos hacemos

una idea de la complejidad y dificultad que implica la implementacin de un sistema

como el descrito.

Hasta hace relativamente poco tiempo, en el mbito de las tecnologas .NET no

exista ningn componente o marco de trabajo capaz de ofrecer una solucin completa

para la problemtica que supone la implementacin de este tipo de aplicaciones.

Ciertamente, existen muchas tecnologas capaces de ofrecer servicios conectados y

desconectados, como los tradicionales Web Services, WCF, o el ms reciente Web

API, pero ninguna de ellas estaba diseada especficamente para entornos de asincrona

y cooperacin en tiempo real entre mltiples usuarios. De hecho, aunque era posible

crear este tipo de sistemas usando dichas plataformas, no era una tarea trivial ni

siquiera para los ms experimentados desarrolladores, y normalmente desembocaba en

la creacin de sistemas muy poco eficientes y con bastantes problemas de rendimiento

y limitaciones en su escalabilidad.

A lo largo de estas pginas veremos cmo podemos implementar sorprendentes

funcionalidades de este tipo utilizando SignalR, un magnfico marco de trabajo potente, flexible y escalable que nos facilitar la tarea hasta el punto de hacerla trivial.

Para lograr este objetivo, comenzaremos haciendo un breve recorrido por los

problemas que encontramos hoy da para desarrollar aplicaciones multiusuario en

Introduccin 21

tiempo real, algunos de los cuales ya hemos adelantado en los prrafos anteriores.

Veremos rpidamente el funcionamiento de HTTP y las limitaciones que presenta para

soportar este tipo de sistemas, e introduciremos el concepto PUSH. Tambin

describiremos los estndares que estn siendo definidos por parte de W3C e IETF y

tcnicas que podemos usar en la actualidad para implementar Push sobre HTTP. Esto

nos permitir lograr un conocimiento profundo del escenario en el que nos

encontramos, y la problemtica existente en torno al desarrollo de aplicaciones que

hagan gala de esa inmediatez e interactividad a las que hemos hecho referencia. Esto,

adems, nos ser de mucha utilidad para comprender mejor cmo funciona SignalR y

las bases sobre las cuales se sustenta.

A continuacin introduciremos formalmente SignalR describiendo sus principales

caractersticas, su posicin en la pila de tecnologas de desarrollo para Internet de

Microsoft, y los distintos niveles de abstraccin que ofrece sobre los protocolos

subyacentes y que nos ayudarn a aislarnos de detalles de bajo nivel y a centrarnos en,

simplemente, crear funcionalidades espectaculares para nuestros usuarios.

Aprovecharemos la ocasin para hablar tambin de OWIN y Katana, dos nuevos

actores que estn tomando protagonismo en distintas tecnologas, entre ellas SignalR.

Estudiaremos muy en profundidad las distintas tcnicas y abstracciones que ofrece

este marco de trabajo para la creacin de aplicaciones interactivas multiusuario en

tiempo real, tanto desde el lado cliente como servidor, y aprenderemos a aprovechar su

potencia y flexibilidad. Para ello, por supuesto, nos apoyaremos en ejemplos de cdigo

que nos ayudarn a entender sus bases de forma prctica, y as ver cmo podemos

utilizar este framework en proyectos reales.

Tambin trataremos la independencia de SignalR respecto a los entornos web,

porque, aunque pueda parecer su entorno natural, este framework va bastante ms all y permite la prestacin de servicios real-time desde cualquier tipo de aplicacin, y, de la misma forma, su consumo desde, prcticamente, cualquier tipo de sistema. Veremos

varios ejemplos prcticos de ello.

Otro aspecto de gran importancia, al que dedicaremos un buen nmero de pginas,

es a revisar el despliegue y la capacidad de escalado de aplicaciones SignalR.

Estudiaremos las herramientas que acompaan de serie a esta plataforma, y plantearemos otras posibles soluciones para cuando estemos ante algn escenario en

los que estas soluciones se nos quedan pequeas. Veremos tambin distintas tcnicas

destinadas a monitorizar el estado de nuestros servidores y a mejorar su rendimiento en

entornos de alta concurrencia.

Y ya por ltimo entraremos en aspectos avanzados de programacin con SignalR,

que permitirn tener una visin ms profunda del funcionamiento del framework, como

los aspectos de seguridad, la creacin de componentes desacoplados usando inyeccin

de dependencias, extensibilidad de SignalR, realizacin de pruebas unitarias y otros

aspectos de inters.

Bienvenido a las aplicaciones multiusuario, asncronas y en tiempo real.

Bienvenido a SignalR!

23

CAPTULO

1.- FUNCIONAMIENTO DE HTTP

HTTP (HyperText Transfer Protocol, o Protocolo de Transferencia Hipertexto) es el idioma en el que conversan cliente y servidor en una aplicacin web. Inicialmente

definido en 19961, la simplicidad y versatilidad de su diseo es, en cierta medida,

responsable del xito y difusin de la web, e internet en general.

Y aunque todava sigue siendo vlido en escenarios web tradicionales, en otros,

como aplicaciones o servicios en tiempo real resulta muy limitado.

Su funcionamiento se basa en un esquema de peticin-respuesta siempre

originada en cliente, lo que suele denominarse modelo Pull: cuando un cliente

necesita acceder a un recurso alojado en un servidor, inicia expresamente una conexin

hacia el mismo, y le solicita la informacin usando para ello el lenguaje definido por el protocolo HTTP. El servidor procesa esta peticin y retorna el recurso requerido

(que puede ser el contenido de un archivo existente o el resultado de ejecutar un

proceso), cerrndose la conexin de forma inmediata.

Si el cliente necesita obtener un nuevo recurso, el procedimiento vuelve a realizarse

desde el principio: se establece la conexin con el servidor, se enva la solicitud del

recurso requerido, el servidor la procesa, enva el resultado y cierra la conexin. Esto

ocurre cada vez que accedemos a una pgina web, o a imgenes u otro tipo de recursos

descargados desde el navegador, por ejemplo.

Como se puede intuir a la vista de la siguiente ilustracin, se trata de un proceso

sncrono. Tras enviar la peticin al servidor, el cliente queda a la espera de la

respuesta, sin hacer nada hasta que sta se encuentra disponible:

1 Especificacin de HTTP 1.0: http://www.w3.org/Protocols/HTTP/1.0/spec.html

HTTP: El cliente es el

que manda

2


Figura 1.- Comunicacin HTTP entre un navegador y un servidor web

Aunque este funcionamiento es el clsico de un sistema web, el mismo protocolo

HTTP puede dar soporte a las necesidades de asincrona de las aplicaciones modernas

gracias a las tcnicas generalmente conocidas por AJAX (Asynchronous JavaScript And XML, o JavaScript Asncrono y XML).

Gracias a ellas, es posible realizar el intercambio de informacin entre cliente y

servidor sin abandonar la pgina actual. El cliente en cualquier momento puede iniciar

una conexin con el servidor usando JavaScript, solicitar un recurso y procesarlo, por

ejemplo actualizando una porcin de pgina.

Lo realmente interesante, y que ha propiciado la aparicin de servicios muy

dinmicos e interactivos como Facebook o Gmail es que estas operaciones se realizan

de forma asncrona, es decir, el usuario puede seguir manejando el sistema mientras

ste, en segundo plano, se comunica con el servidor para enviarle o recibir

informacin.

Figura 2.- Ajax en una pgina Web

Este esquema de funcionamiento sigue utilizando y cindose perfectamente al

protocolo HTTP y al modelo peticin/respuesta originada en cliente. El cliente es

siempre el que tiene la iniciativa y decide cundo conectar con el servidor.

Sin embargo, hay escenarios en los que HTTP no es muy eficiente. Incluso con la posibilidad de usar asincrona, usando este protocolo no es sencillo implementar

aplicaciones de mensajera instantnea o chats, herramientas colaborativas, juegos

online multiusuario o servicios de informacin en tiempo real.

HTTP: El cliente es el que manda 25

Y este es precisamente el problema: HTTP no est orientado al tiempo real. Hay

otros protocolos, como el popular IRC2, que s estn enfocados a conseguir una mayor

inmediatez en las comunicaciones para ofrecer servicios ms dinmicos e interactivos

que los que podemos conseguir usando Pull. En ellos, el servidor puede tomar la

iniciativa y enviar informacin al cliente en cualquier momento, sin esperar a que ste

lo solicite expresamente.

2.- POLLING, LA SOLUCIN?

De forma intuitiva, cuando los desarrolladores web nos enfrentamos a un escenario en

el que necesitamos que sea el servidor el que enve informacin al cliente por iniciativa

propia, la primera solucin que se nos ocurre es utilizar la tcnica denominada Polling, que bsicamente consiste en realizar conexiones peridicas desde el cliente para

comprobar si en el servidor existe alguna actualizacin a tener en cuenta.

Figura 3.- Polling en un servicio de chat

Las principales ventajas de esta solucin son, por un lado, la sencillez de su

implementacin, y por otro, su universalidad de aplicacin: funciona siempre, en

todos los navegadores y servidores, puesto que no hace uso ms que de las

caractersticas estndar de HTTP. Y por supuesto, continuamos utilizando el modelo

Pull.

2 Internet Relay Chat (IRC) protocol: http://www.ietf.org/rfc/rfc1459.txt


Sin embargo, esto tiene un precio a veces excesivo. Las frecuentes conexiones y

desconexiones tienen un coste alto en trminos de ancho de banda y proceso en ambos

extremos de la comunicacin, y lo peor es que este coste aumenta de forma

proporcional a las necesidades de inmediatez en las actualizaciones y al nmero de

clientes que se encuentren, en un momento dato, utilizando el servicio. Es fcil

imaginar la carga que debe soportar un servidor con miles de usuarios conectados

solicitndole actualizaciones varias veces por segundo en una aplicacin que ofrezca

actualizaciones en tiempo real.

Existen tcnicas que mitigan en la medida de lo posible estos problemas. Una de

ellas es utilizar periodicidad adaptativa, de forma que el intervalo entre las consultas

vaya adaptndose a la carga actual del sistema o a las probabilidades de que se

produzcan actualizaciones. Es bastante sencilla de implementar y puede mejorar

considerablemente el consumo de recursos en determinados escenarios.

Otra variante del Polling bastante ms conservadora, aunque deriva en una

experiencia de usuario mucho ms pobre, es la tcnica denominada piggy backing, consistente en no realizar consultas expresas desde el cliente, sino aprovechar cualquier

interaccin de ste con el sistema para actualizarle la informacin que necesite. Por

ejemplo, en un servicio de correo va web, en lugar de realizar una consulta peridica

para comprobar la llegada de nuevos mensajes, esto se comprobara cada vez que el

usuario accediera a una pgina, un mail o cualquier otra funcionalidad. Puede ser

interesante en escenarios en los que no se requiere mucha inmediatez y donde, por las

propias caractersticas del sistema, estemos totalmente seguros de que el usuario

interactuar con la aplicacin frecuentemente.

Por supuesto, estas variantes pueden ser combinadas entre s para lograr un uso ms

eficiente de los recursos y, al mismo tiempo, ofrecer una experiencia de uso razonable.

Por ejemplo, sera posible actualizar el estado de un cliente mediante piggy backing cuando ste interacta con el servidor y, cuando esta interaccin no se produce, usar

Polling con o sin periodicidad adaptativa para obtener las actualizaciones. En definitiva, a pesar de sus inconvenientes, Polling es una opcin razonable

cuando buscamos una solucin sencilla de implementar, utilizable de forma universal,

y en escenarios donde no se requiere una gran frecuencia de actualizacin.

Y de hecho, es muy utilizada en sistemas actuales. Un ejemplo real de aplicacin lo

encontramos en la versin web de Twitter, donde se utiliza Polling para actualizar el

timeline cada treinta segundos.

3.- PUSH: LA INICIATIVA ES DEL SERVIDOR

Ya anteriormente hemos comentado que hay aplicaciones en las que el uso de Pull no es muy eficiente. Entre ellas se encuentran los sistemas de mensajera instantnea,

herramientas colaborativas en tiempo real, juegos online multiusuario, servicios de

difusin de informacin, o cualquier tipo de sistemas en los que es necesario enviar al cliente informacin justo en el momento en que sta se ha generado.


En ellas necesitamos que sea el servidor el que tome la iniciativa, siendo capaz

de enviar informacin al cliente justo cuando se produzca un evento del que debe ser

informado, y no esperar a que el cliente la solicite.

Y precisamente esta es la idea que est por detrs del concepto Push o Server

Push. Esta denominacin no hace referencia a un componente, tecnologa o protocolo:

se trata de un concepto, un modelo de comunicacin entre cliente y servidor donde ste

ltimo es el que toma la iniciativa en la comunicacin.

Tampoco se trata de algo novedoso. Hay protocolos conceptualmente Push como IRC, el protocolo que rige el funcionamiento de los clsicos servicios de chat, o SMTP,

el encargado de coordinar los envos de correos electrnicos, que fueron creados antes

de acuarse el trmino para identificar este tipo de comunicacin.

Para conseguir que el servidor pueda notificar eventos en tiempo real a una serie de

clientes interesados en recibirlos, lo ideal sera poder iniciar desde aqul una conexin

directa punto a punto con ellos. Por ejemplo, un servidor de chat podra mantener una

lista con las direcciones IP de los clientes conectados, y abrir una conexin de tipo

socket hacia cada uno de ellos para notificarles la llegada de un nuevo mensaje. Sin embargo, tcnicamente no es posible. Por razones de seguridad, normalmente

resulta imposible realizar una conexin directa a un equipo cliente debido a la

existencia de mltiples niveles intermedios que la rechazaran, como firewalls, routers o proxies. Por esta razn la prctica habitual es que sea el cliente el que inicia la

conexin y no al contrario.

Para evitar este inconveniente y poder lograr un efecto parecido, hace tiempo

surgieron tcnicas basadas en elementos activos incrustados en las pginas web

(applets Java, Flash, aplicaciones Silverlight). Estos componentes utilizaban normalmente sockets para abrir una conexin persistente con el servidor, es decir, una conexin que permaneca abierta todo el tiempo que el cliente estuviera conectado al

servicio, mantenindose a la escucha por si el servidor tena algo que comunicar. Desde

el lado servidor, cuando se produca un evento de inters para el cliente conectado,

utilizaba ese canal abierto para notificar en tiempo real las novedades.

Este enfoque, aunque ha sido utilizado en multitud de soluciones Push, tiende a

desaparecer. Los componentes activos incrustados en las pginas estn siendo

eliminados de la web a velocidad vertiginosa y sustituidos por alternativas ms

modernas, fiables y universales como HTML5. Asimismo, el uso de conexiones

persistentes de larga duracin basadas en sockets puros son problemticas cuando existen elementos intermediarios (firewalls, proxies) que pueden impedir estas comunicaciones, o cerrar las conexiones tras detectar un periodo de inactividad, y

tambin podan suponer riesgos de seguridad para los servidores.

Dada la necesidad de soluciones fiables que dieran cobertura a este tipo de

escenarios, tanto W3C como IETF, los principales organismos que proponen y definen

los protocolos, lenguajes y estndares para internet, se pusieron a trabajar en dos

estndares que permitieran una comunicacin ms directa y fluida desde el servidor

hacia el cliente, conocidos como WebSockets y Server-Sent Events, ambos englobados bajo el paraguas del nombre comercial HTML5.


3.1.- WebSockets

El estndar WebSockets consiste en una API de desarrollo, que est siendo definida por la W3C (World Wide Web Consortium, http://www.w3.org), y un protocolo de

comunicaciones, en el que est trabajando el IETF (Internet Engineering Task Force, http://www.ietf.org).

Bsicamente, permite establecer una conexin persistente que iniciar el cliente

cuando sea necesario y permanecer abierta de forma continua. Sobre esta conexin se

crea un canal bidireccional entre cliente y servidor donde cualquiera de ellos puede

enviar informacin al otro extremo en cualquier momento.

Figura 4.- Funcionamiento del estndar WebSockets

Aunque en la actualidad las especificaciones tanto del API como del protocolo se

encuentran bastante avanzadas, todava no podemos considerar que la aplicacin de

esta tecnologa sea universal.

Podemos encontrar implementacin de WebSockets en muchos de los navegadores

actuales como IE10/11, Chrome y Firefox, en otros slo encontramos

implementaciones parciales (Opera mini, navegador Android), y en otros simplemente

no est disponible3.

Adems del problema de los distintos niveles de implementacin que encontramos

en el lado cliente, el hecho de que el estndar incluya un protocolo de comunicaciones

independiente, aunque negociado inicialmente sobre HTTP, implica que tambin deben

realizarse cambios en determinados elementos infraestructurales e incluso servidores

para que sean aceptadas las conexiones que utilicen WebSockets.

Por ejemplo, no ha sido posible utilizar fcilmente WebSockets sobre tecnologas

Microsoft hasta la ltima oleada de novedades (Internet Explorer 10, ASP.NET 4.5,

WCF, IIS8), donde ya ha comenzado a soportarse de forma nativa. Desde el punto de vista del desarrollador, WebSockets ofrece un API JavaScript

realmente sencillo e intuitivo para iniciar conexiones, enviar mensajes, y cerrar la

3 Fuente: http://caniuse.com/websockets


conexin cuando ya no sea necesaria, as como eventos para capturar los mensajes

recibidos:

var ws = new WebSocket("ws://localhost:9998/echo");

ws.onopen = function() {

// Web Socket is connected, send data using send()

ws.send("Message to send");

alert("Message is sent...");

};

ws.onmessage = function(evt) {

var received_msg = evt.data;

alert("Message is received...");

};

ws.onclose = function () {

// WebSocket is closed.

alert("Connection is closed...");

};

Como se puede observar, la conexin se inicia simplemente instanciando un objeto

WebSocket apuntando hacia la direccin del endpoint del servicio. La URL utiliza el

protocolo ws:// para indicar que se trata de una conexin WebSockets.

Podemos ver tambin la sencillez con la que es posible capturar los eventos

producidos cuando se consigue abrir la conexin, se reciben datos, o cuando la

conexin ha sido cerrada.

Sin duda, WebSockets es la tecnologa del futuro para la implementacin de

servicios Push en tiempo real.

3.2.- Server-Sent Events (aka API Event Source)

Server-Sent Events, tambin conocido como API Event Source, es el segundo estndar

en el que est trabajando el consorcio W3.

Actualmente este estndar solo es una recomendacin. Aunque en esta ocasin, al

tratarse de un API JavaScript bastante simple y no necesitar cambios en protocolos

subyacentes, su implementacin y adopcin es ms sencilla que con el estndar

WebSockets.

A diferencia de ste, Event Source propone la creacin de un canal unidireccional

desde el servidor al cliente, pero iniciado por el cliente. Es decir, el cliente se

suscribe a un origen de eventos disponible en el servidor y recibe notificaciones cuando se envan datos a travs de ste.

Toda la comunicacin se realiza sobre HTTP; la nica diferencia respecto a una

conexin ms tradicional radica en el uso del content-type text/event-stream en la

respuesta. Indica que la conexin debe mantenerse abierta puesto que ser utilizada

para enviar un flujo continuo de eventos, o mensajes, desde el servidor.


Figura 5.- Funcionamiento del estndar Server-Sent Events

La implementacin en cliente es, si cabe, an ms sencilla que la vista

anteriormente en WebSockets:

var source = new EventSource('/getevents');

source.onmessage = function(event) {

alert(event.data);

};

Como se puede intuir, la instanciacin del objeto EventSource es la que inicia la subscripcin del cliente al servicio cuya URL se suministra en el constructor, y los

mensajes se procesarn en la funcin callback indicada a tal efecto. En la actualidad, prcticamente todos los navegadores soportan este estndar

excepto Internet Explorer y algunos navegadores especficos para dispositivos mviles,

y esto limita su uso en aplicaciones reales. Tambin, aunque el hecho de apoyarse en

HTTP simplifica enormemente su difusin, desde el punto de vista infraestructural

requiere la colaboracin de proxies u otros tipos de intermediarios, que deben ser

capaces de interpretar el content-type utilizado y no procesar las conexiones de la misma forma que las tradicionales, evitando por ejemplo el buffering de respuestas o desconexiones por timeout.

Es importante asimismo destacar la limitacin que implica el hecho de que el canal

establecido por este protocolo sea unidireccional en sentido servidor-cliente: si el

cliente necesita enviar datos al servidor, debe hacerlo mediante otra conexin

distinta, normalmente otra peticin HTTP, lo cual, por ejemplo, implica un consumo

de recursos mayor que lo que supondra el uso de WebSockets en este mismo

escenario.


3.3.- Push hoy

Como hemos visto, tanto los estndares como los browsers se estn preparando para

solucionar los escenarios clsicos Push, aunque actualmente no disponemos de la

seguridad suficiente como para utilizarlos de forma universal.

Sin embargo, Push es algo que necesitamos hoy. Los usuarios exigen aplicaciones

cada vez ms interactivas, giles y colaborativas, y para ello debemos recurrir a

tcnicas que nos permitan conseguir la inmediatez de Push, pero teniendo en cuenta las

limitaciones actuales en navegadores e infraestructura. Y en este momento slo

podemos llegar a ello aprovechando las ventajas de HTTP y su gran difusin.

Partiendo de estas premisas, es fcil encontrar en Internet multitud de propuestas

conceptuales, como Comet, HTTP Push, Reverse AJAX, AJAX Push, etc., cada una

describiendo soluciones (a veces coincidentes) para conseguir los objetivos propuestos.

De la misma forma, encontramos tcnicas concretas que describen cmo implementar

Push sobre HTTP de forma ms o menos eficiente, como Long Polling, XHR Streaming, o Forever Frame.

A continuacin vamos a estudiar dos de ellas, Long Polling y Forever Frame,

bsicamente por dos razones. En primer lugar, porque son las ms universales

(funcionan en todo tipo de sistemas cliente y servidor) y, en segundo, como veremos

ms adelante, porque son utilizadas de forma nativa por SignalR, y as comenzamos a

acercarnos al objetivo de este libro.

3.3.1.- Long polling

Esta tcnica Push es bastante similar a Polling, que ya hemos descrito anteriormente, aunque introduce ciertas modificaciones para ganar en eficiencia e

inmediatez en la comunicacin.

En este caso el cliente tambin realiza sondeos en busca de actualizaciones, pero, a

diferencia de Polling, si no hay datos pendientes de recibir no se cierra automticamente la conexin y se vuelve a intentar un tiempo ms tarde. En Long

Polling, la conexin permanecer abierta hasta que el servidor tenga algo que

comunicar.

La conexin, que es iniciada siempre por el cliente, puede ser cerrada nicamente

por dos motivos:

Cuando el servidor enva datos al cliente a travs de la misma.

Cuando se produce un error de timeout por falta de actividad sobre la conexin.

En cualquiera de los casos se volvera a establecer de forma inmediata una conexin, quedando nuevamente a la espera de actualizaciones.


Esta conexin es utilizada exclusivamente para recibir datos del servidor, por lo que

si el cliente necesita enviar informacin en sentido ascendente abrir una conexin

HTTP paralela exclusivamente para ello.

Figura 6.- Long polling

La principal ventaja de Long Polling es el bajo retardo en la actualizacin del

cliente, puesto que en el mismo momento en que el servidor dispone de datos para

actualizar el estado de cliente, estos seran enviados a travs del canal ya abierto, con

lo cual el otro extremo tendra constancia en tiempo real de los mismos.

Asimismo, dado que se reduce el nmero de aperturas y cierres de conexin, el

aprovechamiento de los recursos en ambos puntos sera muy superior al ofrecido por

Polling.

A da de hoy, se trata de una solucin muy utilizada por su relativa simplicidad de

implementacin y por el hecho de que sea totalmente universal. No se utiliza ninguna

caracterstica especfica de un navegador concreto, slo capacidades ofrecidas por

HTTP.

El consumo de recursos de Long Polling es algo superior a otras tcnicas en las que

se mantiene una conexin permanentemente abierta, puesto que se abren y cierran

bastantes conexiones si el ritmo de actualizaciones es alto, adems de la conexin

adicional que es necesario utilizar cuando el cliente desea enviar datos al servidor. Por

otro lado, el tiempo de conexin hace que pueda existir un cierto delay (retraso) entre notificaciones. Estos retrasos se hacen ms evidentes cuando el servidor debe enviar al

cliente una serie de notificaciones sucesivas. A no ser que implementemos algn tipo

de optimizacin, como por ejemplo agrupar varios mensajes dentro de la misma


respuesta HTTP, cada mensaje tendra que esperar mientras el servidor recibe el

mensaje previo de dicha secuencia, lo procesa, y vuelve a abrir el canal para atender

una nueva peticin.

3.3.2.- Forever frame

La otra tcnica que vamos a estudiar es denominada Forever Frame, y utiliza de

forma muy ingeniosa el tag de HTML para conseguir una conexin abierta de forma permanente, en cierto sentido, de forma muy similar a Server-Sent Events

En lneas generales, consiste en introducir en el marcado de la pgina del cliente un

tag en cuyo origen se establece la URL donde se encuentra escuchando el servidor. El servidor mantendr esta conexin siempre abierta (de ah el forever de su nombre) y la utilizar para ir enviando las actualizaciones en forma de llamadas a

funciones de script definidas en cliente. De alguna forma, podramos considerar que

esta tcnica consiste en realizar un streaming de scripts que son ejecutados en

cliente conforme van siendo recibidos.

El hecho de que la conexin se mantenga siempre abierta supone un mayor

aprovechamiento de recursos, que no son desperdiciados en los procesos de conexin y

desconexin. De esta forma, podemos conseguir prcticamente el ansiado tiempo real

en sentido servidor-cliente.

Al igual que la tcnica anterior, el uso de HTML, JavaScript y HTTP hace que su

mbito de aplicacin sea prcticamente universal, aunque obviamente est muy

orientado a clientes que soporten estas tecnologas, como los navegadores web. Es

decir, la implementacin de otro tipo de clientes como aplicaciones de escritorio, u

otros procesos que acten como consumidores de estos servicios, sera bastante

compleja.

Figura 7.- Forever frame


Tampoco es una tcnica exenta de inconvenientes. En su implementacin es

necesario tener en cuenta que pueden existir timeouts provocados por cliente, servidor, o algn elemento intermediario (como proxies o firewalls). Asimismo, para conseguir la mayor experiencia en tiempo real las respuestas deben ser enviadas de forma

inmediata al cliente, y no retenidas en buffers o cachs.

Tambin, dado que las respuestas seran acumuladas en el interior del iframe, en memoria del cliente, se puede llegar a ocupar demasiada RAM, por lo que es

conveniente reciclar o ir eliminando contenidos de forma peridica. Por ltimo, el hecho de que la conexin slo sea utilizada para enviar datos desde el

servidor al cliente hace necesario el uso de una conexin adicional cuando se desea

realizar una transmisin en sentido contrario, es decir, desde el cliente al servidor.

3.4.- El mundo necesita algo ms que Push

Hasta ahora hemos visto tcnicas que nos permiten conseguir Push, es decir, que el

servidor pueda enviar informacin al cliente de forma asncrona y conforme sta se

vaya produciendo. Le hemos dado la iniciativa a un elemento que normalmente toma

un papel pasivo en la comunicacin con el cliente.

Sin embargo, en el contexto de aplicaciones asncronas, multiusuario y que

funcionan en tiempo real, Push es slo una de las partes imprescindibles. Necesitamos bastantes ms capacidades para conseguir crear estos siempre sorprendentes sistemas,

por citar algunas:

Gestionar usuarios conectados. El servidor debe saber en todo momento qu usuarios estn conectados a los servicios, cules se desconectan, y, en

general, controlar toda la casustica asociada al hecho de realizar seguimiento a un nmero indeterminado de clientes.

Gestionar suscripciones. El servidor debe ser capaz de gestionar suscripciones, o agrupar a los clientes interesados en recibir determinado tipo de mensajes. Por ejemplo, en un servicio de chat, slo los usuarios

conectados a una sala concreta deberan recibir los mensajes enviados a

sta. De esta forma se optimiza el envo y se evita que a los clientes llegue informacin que no les interesa y el derroche de recursos que esto implica.

Recibir y procesar acciones. El servidor no slo debera ser capaz de enviar informacin en tiempo real a los clientes, sino tambin de recibirla y procesarla sobre la marcha.

Realizar seguimiento de envos, puesto que no se puede asegurar que todos los clientes se conectan en las mismas condiciones. Pueden darse

conexiones a distintas velocidades, inestabilidad en las lneas, o cortes

puntuales y esto hace necesario disponer de mecanismos capaces de

encolar mensajes y gestionar de forma individualizada los envos para

asegurar que todos los clientes son actualizados.


Ofrecer un API flexible, capaz de ser consumido de forma sencilla por multitud de clientes, y ms hoy en da, donde existen una gran variedad de dispositivos desde los cuales es posible acceder a servicios online.

Seguro que podramos citar bastantes ms, pero estos ejemplos ya son suficientes

como para ofrecer una idea de la complejidad que supone desarrollar aplicaciones de

este tipo.

Y es aqu donde SignalR entra en escena

Por qu aprender con nosotros?Porque creamos cursos online de calidad contrastada cuyos autores y tutores son reconocidos expertos del sector, aprenders a tu ritmo de la mano de un verdadero especialista y dejars de dar tumbos por internet

buscando cmo se hace cualquier cosa que necesites.

Quieres ms razones? Descbrelas en:

www.campusmvp.es

Creamos los mejores cursos online en espaol para programadores

Descubre todos nuestroslibros para programadoreswww.krasispress.com

PortadaContraportadaAgradecimientosContenidoPresentacin1.- Quin debera leer este libro1.1.- Requisitos previos1.2.- Quin NO debera leer este libro

2.- Esquema del libro2.1.- Por dnde empezar a leer este libro

3.- Convenciones y caractersticas de este libro4.- Requerimientos del sistema5.- Ejemplos de cdigo5.1.- Instalando los ejemplos de cdigo5.2.- Cmo usar los ejemplos de cdigo5.3.- Notas sobre esta versin

CAPTULO 1: Introduccin1.- Internet, asincrona, multiusuario uau!

CAPTULO2: HTTP: El cliente es el que manda1.- Funcionamiento de HTTP2.- Polling, la solucin?3.- Push: la iniciativa es del servidor3.1.- WebSockets3.2.- Server-Sent Events (aka API Event Source)3.3.- Push hoy3.3.1.- Long polling3.3.2.- Forever frame

3.4.- El mundo necesita algo ms que Push

CAPTULO 3: Introduccin a SignalR1.- Presentando a SignalR2.- Qu ofrece SignalR3.- Dos niveles de abstraccin4.- Plataformas soportadas5.- OWIN y Katana, the new kids on the block6.- Instalacin de SignalR

CAPTULO 4: Conexiones persistentes1.- Introduccin2.- Implementacin del lado servidor2.1.- Mapeo y configuracin de conexiones persistentes2.2.- Eventos de una Persistent Connection2.3.- Envos de mensajes a clientes2.4.- Tratamiento asncrono de eventos2.5.- Grupos de conexiones2.6.- La clase de inicializacin OWIN

3.- Implementacin del lado Cliente3.1.- Iniciar la conexin usando el cliente JavaScript3.2.- Soporte para navegadores antiguos3.3.- Soporte para conexiones cross-domain3.4.- Envo de mensajes3.5.- Recepcin de mensajes3.6.- Envo de informacin adicional al servidor3.7.- Otros eventos disponibles en cliente

4.- Negociacin de Transporte5.- Ajuste de parmetros de configuracin de SignalR6.- Ejemplo completo: tracking de visitantes6.1.- Creacin del proyecto e instalacin6.2.- Implementacin del lado cliente6.2.1.- Marcado HTML6.2.2.- Scripts (Scripts/Tracking.js)

6.3.- Implementacin del lado servidor6.3.1.- Conexin persistente (TrackerConnection.cs)6.3.2.- Startup code (Startup.cs)

CAPTULO 5: Hubs1.- Introduccin2.- Implementacin del servidor2.1.- Configuracin y registro de rutas2.2.- Creacin de Hubs2.3.- Recepcin de mensajes2.4.- Envo de mensajes a clientes2.5.- Envo de mensajes a usuarios especficos2.6.- Mantenimiento de estado2.7.- Acceso a informacin del contexto de la peticin2.8.- Notificacin de conexiones y desconexiones2.9.- Gestin de grupos2.10.- Mantenimiento de estado en el servidor

3.- Implementacin del cliente3.1.- Clientes JavaScript3.2.- Generacin del proxyGeneracin manual de proxies JavaScript

3.3.- Establecimiento de la conexin3.4.- Envo de mensajes al servidor3.5.- Envo de informacin adicional3.6.- Recepcin de mensajes enviados desde el servidor3.7.- Logging3.8.- Mantenimiento de estado3.9.- Implementacin del cliente sin proxyEstablecimiento de la conexinInvocacin de mtodos del servidorMantenimiento de estadoRecepcin de mensajes enviados desde el servidor

4.- Ejemplo completo: pizarra compartida4.1.- Creacin del proyecto y puesta en marcha4.2.- Implementacin del lado clienteMarcado HTML (drawingboard.html)Scripts (Scripts/DrawingBoard.js)

4.3.- Implementacin del lado servidorHub (DrawingBoard.cs)Startup code (Startup.cs)

CAPTULO 6: Conexiones persistentes y Hubs desde otros procesos1.- Acceso desde otros procesos2.- Acceso externo usando conexiones persistentes3.- Ejemplo completo: seguimiento de conexiones en el servidor3.1.- Creacin del proyecto y puesta en marcha3.2.- Implementando un sitio web3.2.1.- Marcado de la pgina (default.aspx)3.2.2.- Code-behind (default.aspx.cs)

3.3.- Sistema de trazado de peticiones (lado servidor)3.3.1.- Conexin persistente (ConnectionSpy.cs)3.3.2.- Startup code (Startup.cs)3.3.3.- Clase global de aplicacin (Global.asax.cs)3.3.4.- Cambios opcionales en la configuracin (web.config)

3.4.- Sistema de trazado de peticiones (lado cliente)3.4.1.- Pgina de espionaje (spy.html)

4.- Acceso externo Usando Hubs5.- Ejemplo completo: Barra de progreso5.1.- Creacin del proyecto y puesta en marcha5.2.- Implementacin del lado cliente5.2.1.- Marcado HTML (progress.html)5.2.2.- Estilos (Styles/ProgressBar.css)5.2.3.- Script (Scripts/ProgressBar.js)

5.3.- Implementacin del lado servidor5.3.1.- Hub5.3.2.- Proceso costoso (HardProcess.Aspx)5.3.3.- Startup code (startup.cs)

CAPTULO 7: Aplicaciones real-time multiplataforma1.- Signalr en la web y ms all2.- Servidores SignalR multiplataforma2.1.- Hosting de SignalR en aplicaciones no web2.1.1.- Hosting en una aplicacin de consola2.1.2.- SignalR en un servicio Windows

2.2.- Hosting de SignalR en plataformas no Windows

3.- Clientes SignalR multiplataforma3.1.- Acceso a servicios desde clientes .NET no web3.1.1.- Creacin y apertura de una Conexin Persistente3.1.2.- Envo y recepcin de datos usando Conexiones Persistentes3.1.3.- Creacin y apertura de conexiones a Hubs3.1.4.- Comunicacin con el servidor usando Hubs3.1.5.- Logging3.1.6.- Ejemplo: aplicacin de consola3.1.7.- Ejemplo: aplicacin Windows 8/ Windows 8.1 con C#/XAML3.1.8.- Clientes Windows Phone 8

3.2.- Consumo de servicios desde otras plataformas

CAPTULO 8: Desplegando y escalando SignalR1.- Despliegue de aplicaciones SignalR2.- Los problemas del crecimiento3.- Escalabilidad en SignalR4.- Escalando sobre backplanes4.1.- Service bus de Windows Azure4.1.1.- Configuracin del servicio4.1.2.- Activacin del backplane

4.2.- SQL Server4.2.1.- Configuracin de la base de datos4.2.2.- Activacin del backplane

4.3.- Redis4.3.1.- Instalacin de Redis4.3.2.- Activacin del backplane

5.- Backplanes personalizados6.- Mejora de rendimiento en servicios SignalR6.1.- Configuracin de servidores6.2.- Monitorizacin de rendimiento6.2.1.- Actividad en conexiones6.2.2.- Errores6.2.3.- Actividad en el bus de mensajera6.2.4.- Bus de proveedores de scaleout6.2.5.- Otros contadores de rendimiento interesantes

CAPTULO 9: Temas avanzados1.- Autorizacin en SignalR1.1.- Control de acceso en Conexiones Persistentes1.2.- Control de acceso en Hubs1.3.- Autenticacin del cliente

2.- Un framework extensible3.- Inyeccin de Dependencias3.1.- Inyeccin manual de dependencias3.2.- Liberacin de dependencias3.3.- Contenedores de Inversin de Control3.3.1.- SignalR con Unity3.3.2.- SignalR con Ninject

4.- Pruebas unitarias con SignalR4.1.- Introduccin muy (pero muy) rpida al unit testing4.2.- Unit testing de Hubs4.3.- Unit testing de Conexiones Persistentes

5.- Intercepcin de mensajes en Hubs6.- Integracin con otros frameworks6.1.- WebAPI6.2.- ASP.NET MVC6.3.- Knockout6.4.- AngularJS

ndice analtico

ASP.net SignalR 2.0 - José María Aguilar - Krasis Press

Documents

Transcript of ASP.net SignalR 2.0 - José María Aguilar - Krasis Press