You are on page 1of 35

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.

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

vii

viii Programacin con ASP.Net SignalR 2.0

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


1.2.3.4.5.6.-

Presentando a SignalR .............................................................................................................. 37


Qu ofrece SignalR.................................................................................................................... 39
Dos niveles de abstraccin ..................................................................................................... 40
Plataformas soportadas ............................................................................................................ 41
OWIN y Katana, the new kids on the block ...................................................................... 42
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

viii

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

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.2.3.4.-

Despliegue de aplicaciones SignalR ..................................................................................... 179


Los problemas del crecimiento............................................................................................ 181
Escalabilidad en SignalR .......................................................................................................... 184
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

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
xiii

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

<script src=/scripts/jquery.signalR-2.0.0.min.js></script>

una vez instalada la versin 2.0.1 de SignalR, el cdigo debera cambiarse por:
<script src=/scripts/jquery.signalR-2.0.1.min.js></script>

CAPTULO

Introduccin

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.
19

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!

CAPTULO

HTTP: El cliente es el
que manda

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:

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


23

24 Programacin con ASP.Net SignalR 2.0

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 IRC 2, 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.

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

26 Programacin con ASP.Net SignalR 2.0

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.

HTTP: El cliente es el que manda 27

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.

28 Programacin con ASP.Net SignalR 2.0

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

Fuente: http://caniuse.com/websockets

HTTP: El cliente es el que manda 29

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.

30 Programacin con ASP.Net SignalR 2.0

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.

HTTP: El cliente es el que manda 31

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.

32 Programacin con ASP.Net SignalR 2.0

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

HTTP: El cliente es el que manda 33

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 <iframe> 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 <iframe> 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

34 Programacin con ASP.Net SignalR 2.0

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.

HTTP: El cliente es el que manda 35

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

Creamos los mejores cursos online en espaol para programadores

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

Descubre todos nuestros


libros para programadores

www.krasispress.com