Serialización de alto desempeño: Protocol Buffers

El 11 de octubre de 2011 liberé la versión 1.6.0 de jAlarms, y una de las características nuevas de esta versión es la posibilidad de poner un servicio de envío remoto de alarmas.

Una manera de lograr esto es con RMI, de lo cual ya hablaré posteriormente, pero una manera mucho más eficiente es con los Protocol Buffers de Google. Esta es una herramienta bastante buena para comunicación en red, de hecho es lo que usa Google para la comunicación entre sus procesos, porque ofrece las siguientes ventajas:

• Alto desempeño para serializar y de-serializar objetos.
• Portabilidad e interoperabilidad: permite comunicación entre aplicaciones hechas en distintos lenguajes y plataformas.
• Ancho de banda/espacio: los mensajes serializados ocupan muy poco espacio en comparación con otros formatos como XML, JSON, o incluso serialización binaria nativa de varias plataformas.

Algunas de esas características probablemente les suenen conocidas. Son las promesas de los web services, SOAP-RPC, etc. Para comparaciones me remito a un benchmark muy completo que compara Protocol Buffers con Thrift (una alternativa similar de Apache), XML, JSON, serialización nativa de Java... el ganador es Protocol Buffers, por mucho. Diez veces más rápido que la serialización nativa de Java...

Pero bueno, ¿cómo se usa? Pues resulta que necesitamos un compilador... lo pueden construir a partir de los fuentes, bajando la versión más reciente de la página oficial (2.4.1 cuando escribí esto). Un simple   y al cabo de unos minutos tienen   instalado.

Integración a un proyecto

Para no estarme complicando con plugins en un IDE o tener que llamar el compilador de protobuf a mano, me puse a buscar y resulta que hay un plugin para Gradle, lo cual creo que facilita mucho las cosas. Simplemente definimos un nuevo source set en src/main/proto, en donde vamos a poner nuestros mensajes de protobuf.

Archivos .proto

Para usar protobuf, hay que definir los mensajes que se desea enviar. Un mensaje es un conjunto de propiedades, como si se definiera un bean de Java. Hay que indicar el tipo y nombre de cada propiedad, e indicar si es opcional u obligatoria.

Estos mensajes son procesados por un compilador, llamado  , que los convierte a código fuente de otro lenguaje, que puede ser Java, Python, C#, C++, Ruby, Perl, PHP, etc. Una vez que se compila el mensaje al lenguaje destino, ese código se compila o se utiliza directamente ya en la plataforma destino (por ejemplo, código Java se compila a bytecode, pero código Ruby o PHP se puede utilizar ya directamente).

En mi caso, lo que implementé fue un envío de alarma de un lado a otro; solamente necesito tres propiedades, dos opcionales y una obligatoria. La obligatoria es el mensaje de alarma y las opcionales son la fuente de la alarma, y una bandera indicando si se debe enviar forzosamente o sólo si no ha sido enviada muy recientemente. De modo que mi mensaje queda así:

Los mensajes se pueden definir dentro de un paquete, para evitar colisiones (similar a Java). Pero son simples nombres; cuando esto se compile a Java, queremos tener un paquete que sea significativo en Java.

En el script de Gradle hay que indicar el plugin, que por ahora no está todavía incluido en los oficiales, de modo que hay que jalarlo de Maven Central. También hay que incluir la biblioteca protobuf, para que el código Java generado por el   pueda ser compilado por  :

Al ejecutar Gradle, primero pasa por la fase de protoc, que genera un archivo AlarmProtos.java el cual contiene varias clases; este archivo es agregado al source set principal para que sea compilado ya como cualquier otra clase Java.

La manera de crear un mensaje (tipo Alarm en mi caso), es muy simple: el código contiene un builder el cual configuramos con los datos que queremos y al final le pedimos que nos haga un mensaje. Los mensajes generados son inmutables. Entonces:

Las propiedades marcadas como opcionales nos las podemos saltar, pero las obligatorias hay que ponerles valor o al momento de invocar   se arrojará una excepción tipo   indicándonos los campos obligatorios a los que no pusimos valor.

Una vez que tenemos el mensaje, lo único que tenemos que hacer es escribirlo a un stream:

La diferencia entre ambos métodos es que el segundo antepone la longitud completa del mensaje, para que quien lo tenga que leer pueda saber cuántos bytes esperar. Para leer mensajes de un stream, simplemente:

El primer método es para leer mensajes que fueron escritos con   y el segundo para mensajes escritos con  .

De modo que escribir la comunicación completa utilizando sockets queda bastante sencilla.

Detalles

Me encontré con un par de detalles que me costó un poco de trabajo arreglar, pero a fin de cuentas lo pude resolver.

La naturaleza de la conexión que quiero manejar es algo peculiar: los clientes idealmente casi no se conectan al servidor, más que cuando tienen problemas (y por eso quieren enviar una alarma). Pero cuando hay problemas, es común que no se envíe una alarma, sino cientos o hasta miles; del lado del servidor se filtran todos esos envíos con los mecanismos que ya tiene jAlarms desde versiones anteriores. Para no replicar toda esa funcionalidad en el cliente, lo más sencillo es enviar TODAS las alarmas al servidor. Por eso elegí protobuf, para que no cueste mucho tiempo el envío, y no se acabe el ancho de banda, etc.

Pero en cuanto a recursos, no quiero tampoco mantener constantemente una conexión abierta entre cliente y servidor, si la mayor parte del tiempo no se va a usar. Pero tampoco quiero usar una conexión para enviar un solo mensaje. Lo mejor es abrir una conexión y poder reutilizarla si es que hay varias alarmas que enviar, pero cerrarla después de un periodo (corto) de inactividad. Me decidí por hacer ese periodo 5 segundos. Entonces, cuando el servidor recibe una conexión, la debe mantener abierta en un ciclo donde lee alarmas para procesarlas, pero si pasan 5 segundos y no llegan más, que cierre la conexión.

Resulta que no es suficiente con ponerle   al Socket; no sé cómo lee del socket el método  , pero no detecta el timeout. De modo que tuve que interponer una lectura de un solo byte entre cada lectura de mensaje; esa lectura bloquea el hilo que lee, pero máximo durante 5 segundos y después de ese tiempo se arroja una   la cual puedo cachar para cerrar la conexión.

Del lado del cliente, tengo que tener en cuenta que si han pasado más de 5 segundos desde la última alarma que se envió, lo mejor es cerrar la conexión y abrir una nueva.

De modo que eso es lo que tengo en el cliente, y también en el servidor.

Otros usos

Este fue un uso que le di a Protocol Buffers, y es un uso común (Google creó esta herramienta precisamente para comunicación entre procesos, usando sockets). Pero el intercambio de un alto volumen de mensajes no es el único uso que se le puede dar. Dado que lo que hace en esencia es serializar y deserializar datos a muy alta velocidad y con un formato bastante compacto, se presta también para usarse en conjunto con caches como memcached, Redis, etc.

También se puede usar para guardar datos en sistemas de almacenamiento NoSQL como Cassandra, MongoDB, etc, por las mismas razones: alta velocidad de serialización, formato compacto y portabilidad.

Por ahora, ya tengo una herramienta más a mi disposición para cuando necesite intercambiar datos entre aplicaciones, incluso si están sobre distintas plataformas. Especialmente si están en distintas plataformas. El XML es muy bueno para ser parseado por humanos; para la comunicación entre distintas piezas de software, dejemos que utilicen formatos binarios compactos y de alto desempeño.