Bosque Viejo http://bosqueviejo.net Sitio web sobre programación, software libre, redes, servidores, ofimática... y todo lo relacionado con la informática que nos rodea Tue, 08 May 2012 14:40:56 +0000 es hourly 1 http://wordpress.org/?v=3.3.2 Juggernaut: invirtiendo el paradigma cliente/servidor http://bosqueviejo.net/2012/05/08/juggernaut-invirtiendo-el-paradigma-clienteservidor/ http://bosqueviejo.net/2012/05/08/juggernaut-invirtiendo-el-paradigma-clienteservidor/#comments Tue, 08 May 2012 14:40:56 +0000 bombadil http://bosqueviejo.net/?p=1371 Juggernaut, además de ser un personaje del universo Marvel, es un servidor escrito en Node.JS, que permite su integración con Ruby on Rails para realizar el intercambio de mensajes en dirección del servidor hacia el navegador.

Este esquema permite al servidor poder enviar mensajes al navegador en cualquier momento, de modo que se mantiene una actualización mucho más precisa que con refrescos esporádicos del navegador web hacia el servidor.

¿Cómo funciona?

Juggernaut, para conseguir esto se basa en el uso de un código en Flash que le permite abrir un socket y mantener la comunicación con el servidor de forma constante. En la parte del cliente, por lo tanto, está el navegador que realiza las peticiones al código de Rails como siempre y, además, el código Flash que abre la comunicación con el servidor de Juggernaut, que le va enviando código en JavaScript que ejecuta para realizar acciones concretas.

En la parte del servidor tenemos también dos elementos bien diferenciados, por un lado tenemos al servidor de Juggernaut ejecutándose en el puerto 5001 (por defecto) y el servidor de Rails ejecutándose en otro puerto (por defecto en desarrollo suele ser el 3000). La comunicación con el servidor de Rails es como siempre en protocolo HTTP, mientras que el intercambio de información a través del interfaz de Juggernaut se sucede en formato JSON, enviando información específica a ejecutar en el navegador.

Instalación

La verdad es que la instalación no queda nada clara, por lo que voy a explicar el cómo se instala el sistema para tenerlo funcionando en poco tiempo. En principio, necesitamos ejecutar lo siguiente:

gem install json
gem install eventmachine
gem install juggernaut
gem install maccman-juggernaut -s http://gems.github.com

Tenemos que crear un proyecto Rails. En principio, tendrá que ser una versión anterior a la 3.2, ya que en esa versión se ha eliminado el uso de plugins en favor de las gemas, por lo que, creamos nuestro proyecto Rails y ejecutamos:

ruby script/plugin install git://github.com/maccman/juggernaut_plugin.git

Ahora toca lanzar la parte servidora de Juggernaut, para eso, vamos a generar un fichero de configuración, el sistema nos puede generar uno automáticamente de la siguiente forma:

juggernaut -g juggernaut.yml

Con esto ya tenemos instalado todo el sistema de Juggernaut, y lo básico para poder integrarlo dentro de nuestro proyecto Rails.

Implementando Juggernaut en Rails

Introducir Juggernaut en Rails es tan sencillo como crear un nuevo controlador, por ejemplo uno llamado Chat, y escribir el siguiente código en el fichero chat_controller.rb:

class ChatController < ApplicationController
  def index
  end
 
  def send_data
    render :juggernaut do |page|
        page.insert_html :top, 'chat_data', "<li><strong>#{params['id']}</strong>: #{h params['chat_input']}</li>"
    end
    render :nothing => true
  end
 
end

En este código tenemos dos entradas, una es el index que lo emplearemos para entrar en la página inicial, y otra es la parte de envío de datos, a la que llamaremos mediante AJAX. El formulario lo montamos de la siguiente forma en el fichero index.html.erb:

<html>
<head>
    <title>Chat</title>
    <%= javascript_include_tag :defaults, :juggernaut %>
    <%= juggernaut(:client_id => params[:id]) %>
</head>
<body>
    <%= form_remote_tag(
          :url => { :action => :send_data },
          :complete => "$('chat_input').value = ''" ) %>
    <%= text_field_tag( 'chat_input', '', { :size => 20, :id => 'chat_input'} ) %>
    <%= hidden_field_tag( 'id', params[:id] ) %>
    <%= submit_tag "Add" %>
    </form>
    <ul id="chat_data" style="list-style:none">
    </ul>
</body>
</html>

Lanzando la aplicación

Lanzamos Rails (ya sea con mongrel, thin o cualquier otro servidor) y Juggernaut. El lanzamiento de Juggernaut lo podemos hacer de la siguiente forma:

juggernaut -c juggernaut.yml

Ahora vamos al navegador, abrimos dos navegadores:

Si vamos escribiendo en una ventana, veremos como van apareciendo los textos en ambas, algo como esto:

Con lo que comprobamos que el sistema funciona correctamente.

Algunas pegas

Como hemos visto desde el principio, la comunicación del navegador se realiza a través de un puerto que no es el 80, típico del protocolo HTTP, y que tampoco es protocolo HTTP lo que transita por ese puerto, por lo que, en instalaciones con acceso a Internet restringido, es posible que este sistema no funcione correctamente.

Además, se suma el problema de que el puerto 5001 debe de mantenerse abierto hacia Internet, si no configuramos con suficiente seguridad, a través del fichero juggernaut.yml el sistema, podemos encontrarnos un verdadero agujero de seguridad… ya depende de para qué usemos Juggernaut, pero teniendo en cuenta de que ejecuta código JavaScript en el cliente, podría ser algo nocivo.

Conclusiones

Esta aproximación al sistema de Juggernaut ha sido bastante interesante para descubrir una forma de realizar este tipo de comunicaciones entre cliente y servidor de forma inversa, es decir, que el servidor pueda enviar información al cliente sin que el cliente la solicite. No obstante, los navegadores actuales implementan un sistema denominado websocket que tenderá a sustituir estos mecanismos artesanos de una forma más estándar y frameworks como ChicagoBoss ya lo implementan de forma nativa. El futuro nos mostrará los caminos que se van tomando, de momento, Juggernaut es una muy buena solución para todos los navegadores web actuales.

]]> http://bosqueviejo.net/2012/05/08/juggernaut-invirtiendo-el-paradigma-clienteservidor/feed/ 0 Estructura Lider/Trabajador en Erlang http://bosqueviejo.net/2012/05/07/estructura-lider-trabajador-en-erlang/ http://bosqueviejo.net/2012/05/07/estructura-lider-trabajador-en-erlang/#comments Mon, 07 May 2012 11:22:51 +0000 bombadil http://bosqueviejo.net/?p=1359 Erlang es muy bueno para programación distribuida, y paralela, y concurrente, así mismo se hace muy simple la creación de servidores, tal y como he mostrado en entradas anteriores (servidor UDP y servidor TCP), pero nos queda una tipo de comportamiento que es algo complejo llevar a la práctica. Me refiero al paradigma de Maestro-Esclavo.

La teoría

El paradigma Maestro-Esclavo se basa en que, para acceder a un recurso que está disponible solo desde un punto o solo para un servicio, ya sea por que su acceso es crítico en concurrencia o porque solo se pueda acceder desde un único punto cada vez, se hace necesaria una estructura en la que un único punto sea el responsable de ese acceso, quedando todos los demás supeditados a este.

Esto genera igualmente un problema de cuello de botella, pero la misión no es distribuir, en este caso, para ganar más potencia de procesamiento, sino conseguir: una mayor alta disponibilidad para un recurso accesible solo desde un punto cada vez.

En la terminología de Erlang, la nomenclatura empleada es líder (leader) para referirse al maestro elegido cada vez, y trabajador (worker) para referirse a los esclavos. Esto es así por dos sutiles diferencias que existen entre el modelo clásico de maestro-esclavo frente a este de lider-trabajador:

  • El maestro es siempre uno y se carga con las tareas de replicación y de escritura, el líder, sin embargo, se carga con todas las tareas y no replica nada entre sus trabajadores.
  • El esclavo se encarga de las tareas más frecuentes, en su caso, las lecturas, sin pedir nada al maestro. Si le llega una escritura puede remitirla a su maestro o ignorarla, depende de la implementación. El trabajador, sin embargo, delega todos los trabajos al líder.
  • Cuando un maestro muere, los esclavos quedan atendiendo lecturas, pero el sistema de escritura queda sin servicio, a menos que haya algún mecanismo que permita, por alta disponibilidad, levantar a otro maestro, pero no es la base del paradigma. Cuando un líder muere, en cambio, de entre los trabajadores se elige a un nuevo líder, que se encarga de las peticiones. El esquema está pensado en sí para tener una alta disponibilidad.

Aunque es un comportamiento bastante básico, aún no se ha introducido en la base de Erlang, ya que sus algoritmos de elección han sufrido cambios, incluso hasta hace pocos meses. Supongo que incluso aún habrá algún que otro cambio más, por lo que conviene mantenerse al día. El repositorio oficial (de momento) es este de github, gen_leader_revival de abecciu.

Los autores de la base son Andrew Thompson, Dave Fayram, Hans Svensson y Ulf Wiger.

La implementación

El código podemos descargarlo del repositorio indicado anteriormente, solo necesitaremos el código de gen_leader.erl y el código de skeleton.erl.

La plantilla nos da lo básico para que el gen_leader funcione. Si compilamos ambas y lanzamos desde una consola el skeleton, podemos ver que funciona correctamente. Es más, vamos a modificarlo muy poquito agregando solo impresiones por pantalla para saber en qué momento se ejecuta cada uno:

elected(State, Election, undefined) ->
    Synch = [],
    io:format("no one elected? ~p~n", [Election]),
    {ok, Synch, State};
 
elected(State, Election, Node) ->
    io:format("elected node [~p]: ~p~n", [Node, Election]),
    {reply, [], State}.
 
surrendered(State, Synch, Election) ->
    io:format("surrendered (~p): ~p~n", [Synch, Election]),
    {ok, State}.
 
handle_leader_call(Request, _From, State, Election) ->
    io:format("leader_call (~p): ~p~n", [gen_leader:leader_node(Election), Request]),
    {reply, ok, State}.
 
from_leader(Synch, State, Election) ->
    io:format("from_leader (~p): ~p~n", [gen_leader:leader_node(Election), Synch]),
    {ok, State}.
 
handle_DOWN(Node, State, Election) ->
    io:format("DOWN (~p): ~p~n", [Node, gen_leader:leader_node(Election)]),
    {ok, State}.

El código modificado es llamado como callback cuando se suceden las siguientes situaciones:

  • elected (con nodo undefined), es llamada cuando el nodo es elegido para ser líder, si la variable de Nodo no es undefined, entonces es llamado cuando un nuevo trabajador se ha unido al líder.
  • surrendered, llamada en trabajadores cuando un líder ha sido elegido, o cuando un nuevo nodo entra en el clúster, y se decide de nuevo quién es el líder, siendo llamado elected en el líder elegido y surrendered en el nuevo trabajador.
  • handle_leader_call, esta llamada la realiza quien necesita algo del cluster, o cualquiera de los trabajadores al líder, pero en esencia, solo se proces en el líder.
  • from_leader, mensajes que se emiten desde el líder hacia los trabajadores. Si la devolución de handle_leader_call es {reply, Reply, Broadcast, State}, se envía el mensaje de Broadcast a todos los trabajadores, con lo que pueden hacer alguna sincronización con su estado interno o realizar la acción que se requiera.
  • handle_DOWN, mensaje de caída recibida por el líder de los nodos que han caído. Cuando cae el líder, un nuevo líder es elegido y se le envía la señal de caída del nodo del antiguo líder.

Teniendo estas características en cuenta, podemos ejecutar el código y ver cómo se comporta:

En lider1@bosqueviejo:

(lider1@bosqueviejo)1> {ok, Pid} = datos:start_link(['lider1@bosqueviejo', 'lider2@bosqueviejo']).
no one elected? {election,<0.55.0>,none,datos,lider1@bosqueviejo,
                          [lider1@bosqueviejo,lider2@bosqueviejo],
                          [],
                          [lider2@bosqueviejo],
                          [],[],none,norm,
                          {1,6,0},
                          [],[],5000,
                          {interval,#Ref<0.0.0.49>},
                          lider2@bosqueviejo,6,1,sender}
{ok,<0.55.0>}

Ahora levantamos en lider2@bosqueviejo:

(lider2@bosqueviejo)1> {ok, Pid} = datos:start_link(['lider1@bosqueviejo', 'lider2@bosqueviejo']).
{ok,<0.55.0>}
surrendered ([]): {election,<6327.55.0>,none,datos,lider1@bosqueviejo,
                            [lider1@bosqueviejo,lider2@bosqueviejo],
                            [],[],
                            [{lider1@bosqueviejo,lider1@bosqueviejo},
                             {#Ref<0.0.0.59>,lider1@bosqueviejo},
                             {#Ref<0.0.0.57>,lider1@bosqueviejo}],
                            [],none,norm,
                            {1,6,0},
                            [],[],5000,undefined,undefined,5,1,sender}

En lider1@bosqueviejo se sucede el siguiente mensaje al levantar al lider2@bosqueviejo:

elected node [lider2@bosqueviejo]: {election,<0.55.0>,none,datos,
                                       lider1@bosqueviejo,
                                       [lider1@bosqueviejo,lider2@bosqueviejo],
                                       [],[],
                                       [{#Ref<0.0.0.74>,lider2@bosqueviejo}],
                                       [],none,norm,
                                       {1,6,0},
                                       [],[],5000,
                                       {interval,#Ref<0.0.0.49>},
                                       lider2@bosqueviejo,6,1,sender}

Ahora en lider1@bosqueviejo enviamos un mensaje:

(lider1@bosqueviejo)2> gen_leader:leader_call(Pid, "hola").
leader_call (lider1@bosqueviejo): "hola"
ok

Y lo que pasaba al mismo tiempo en lider2@bosqueviejo:

from_leader (lider1@bosqueviejo): [118,117,101,115,116,114,111,32,108,105,100,
                                   101,114,32,100,105,99,101,58,32,"hola",
                                   "\n"]

En caso de que salgamos de la consola del lider1@bosqueviejo vemos lo siguiente en lider2@bosqueviejo:

no one elected? {election,<0.55.0>,<6327.55.0>,datos,lider2@bosqueviejo,
                          [lider1@bosqueviejo,lider2@bosqueviejo],
                          [],
                          [lider1@bosqueviejo],
                          [{#Ref<0.0.0.59>,lider1@bosqueviejo},
                           {#Ref<0.0.0.57>,lider1@bosqueviejo}],
                          [],none,norm,
                          {2,5,1},
                          [],[],5000,
                          {interval,#Ref<0.0.0.75>},
                          lider2@bosqueviejo,5,2,sender}
DOWN (lider1@bosqueviejo): lider2@bosqueviejo

Es decir, se elige a un nuevo líder y se envía el mensaje de caída del líder.

Conclusiones

Este esquema es bastante útil ya que simplifica el problema de tener varios servidores, por ejemplo, y recursos que solo pueden estar disponibles en un solo servidor cada vez. Por ejemplo, el acceso a un recurso propietario que solo nos da una licencia de uso, el acceso con control de concurrencia a un recurso.

Su interfaz de broadcast, permite que el sistema pueda recibir peticiones de lectura y escritura, haciendo que su broadcast deje la información en cada worker para, en caso de que cayese el líder, puedan seguir funcionando sin problema alguno.

Realmente, otro elemento más para facilitar la creación de sistemas servidores de alta disponibilidad en Erlang.

]]> http://bosqueviejo.net/2012/05/07/estructura-lider-trabajador-en-erlang/feed/ 0 UUID: Identificador Único Universal http://bosqueviejo.net/2012/04/26/uuid-identificador-unico-universal/ http://bosqueviejo.net/2012/04/26/uuid-identificador-unico-universal/#comments Thu, 26 Apr 2012 05:00:12 +0000 bombadil http://bosqueviejo.net/?p=1333 Últimamente, cada más sistemas, y cada más sitios emplean algo llamado UUID, cuyas siglas vienen a decir: Universally Unique ID; aunque suene algo arrogante, el cálculo de un UUID casi que podríamos decir que garantiza el que sea único. Es más, su grado de colisión es tan bajo que si lo colocásemos como identificador de clave primaria de una tabla que alberga elementos recogidos aleatoriamente de otras tablas de bases de datos de todo el mundo, que hayan empleado este tipo de dato, garantizamos que no habrá repetidos.

Suena excitante, pero…

¿Cómo funciona esto?

Referenciado en el RFC 4122 del IETF, el UUID se puede definir como un número de 16 bytes (128-bits) que se representa por 32 dígitos hexadecimales, mostrados en cinco grupos separados por guiones:

12345678-abcd-1b3d-a2c4-0123456789ab

Cada uno de los cinco grupos identifica un dato específico para garantizar su carácter único. En principio, se toma el timestamp de la hora actual con precisión de 100 nanosegundos y en formato UTC desde el 15 de octubre de 1582 (la fecha de la reforma gregoriana para el calendario cristiano) de la siguiente forma:

  • time_low el campo bajo del timestamp, este ocupa los primeros 32 bits.
  • time_mid el campo medio del timestamp, ocupa los siguientes 16 bits.
  • time_high la última parte del timestamp, este no ocupa todo el grupo, sino solo los bits de menor peso, los primeros 12 bits.

Para llegar a los primeros 64 bits nos faltan 4, esto es porque estos se emplean para identificar la versión de UUID que se emplea, según el RFC4122, de momento se contemplan 5:

  1. Versión basada en tiempo. Especificada en el RFC4122.
  2. Versión de Seguridad DCE con UIDs POSIX embebidos.
  3. Versión basada en nombre que usa MD5 (también se especifica en el RFC4122).
  4. Versión aleatoria o pseudo-aleatoria de generación (también se especifica en el RFC4122).
  5. Versión basada en nombre que usa SHA-1 (también se especifica en el RFC4122).

El 4º campo se divide en dos, pero para un mismo concepto, que es la secuencia de reloj. Se escribe con datos de 8 bits especificando el de mayor y menor peso, quedando en este orden almacenados en el cuarto grupo. Aunque el grupo ocupa 16 bits, las versiones 3, 4 y 5 lo emplean como un dato de 14 bits, siendo en las versiones 3 y 5 una secuencia de reloj construida desde un nombre, y en la versión 4 una secuencia de reloj aleatoria o pseudo-aleatoria.

El 5º grupo es denominado el nodo. Ocupa 48 bits. En la versión 1 de UUID este dato se corresponde con la dirección MAC (dirección física de una interfaz de red) definida en el IEEE 802. Para equipos sin interfaz de red, se emplea un dato aleatorio o pseudo-aleatorio. Para las versiones 3 y 5 de UUID, este dato cambio construyéndose a través de una elección de nombre y codificándola con MD5 o SHA-1. Para la versión 4, este dato se construye a través de un número aleatorio o pseudo-aleatorio.

Conclusiones

Los UUID son identificadores únicos y muy difíciles de que se produzcan dos iguales dados los parámetros que se emplean para su generación. Al igual que los datos que se emplean para la generación del conference ID de la comunicación de H.323, este dato puede ser empleado como identificador de tablas y estar seguro que, aunque la tabla esté fraccionada y después se mezcle en una, los datos no colisionarán nunca.

]]> http://bosqueviejo.net/2012/04/26/uuid-identificador-unico-universal/feed/ 0 Cassandra: la NoSQL de facebook http://bosqueviejo.net/2012/04/25/cassandra-la-nosql-de-facebook/ http://bosqueviejo.net/2012/04/25/cassandra-la-nosql-de-facebook/#comments Wed, 25 Apr 2012 05:00:42 +0000 bombadil http://bosqueviejo.net/?p=1328 Tras haber visto Riak un poco más de cerca, ahora le toca el turno a Cassandra. Esta base de datos NoSQL fue desarrollada en el seno de Facebook, como una de sus 7 tecnologías clave. En 2008 fue donada a Apache y desde entonces su popularidad ha ido creciendo cada vez más.

La ventaja de Cassandra es su capacidad de escalar a través de una configuración de anillo en un cluster. La información de la base de datos se distribuye entre todos los nodos configurados y puede ser accedida desde cualquiera de ellos. En este caso, la distribución es muy parecida a Riak, incluso emplean el mismo protocolo para intercomunicación entre nodos: Gossip; además, se requiere de generar un token especial balanceado para la configuración de cada nodo de Cassandra. En esta página hay un código escrito en Python para poder hacer esta tarea.

El acceso a la base de datos se realiza mediante RPC y usando Thrift, que representa otra de las 7 tecnologías clave de Facebook, y también liberada como software libre. Como Thrift es multi-lenguaje, está implementado en muchos de los lenguajes existentes, no hay problemas de implementación, ya sea en Python, Perl, PHP, Java, Erlang, etc.

¿Es NoSQL?

En un principio, usando la base de Thirft y las funciones estándar que podemos ver en cualquier documentación, podríamos decir que sí es NoSQL. Nos proveen de funciones para realizar un CRUD básico a través de la inserción, actualización, eliminación y obtención de datos desde la base de datos. No obstante, la búsqueda queda un poco en el aire, ya que para poder buscar por cualquiera de las columnas creadas, hay que prefijar un índice.

Vamos al principio para entenderlo mejor. Haciendo una similitud con el modelo relacional, podemos ver que Cassandra dispone de los siguientes elementos:

  • Keyspace: debe de crearse un keyspace para almacenar la información y, a la hora de conectar, hay que indicar que keyspace se quiere utilizar. Esto es similar a lo que en las bases de datos tradicionales es la base de datos en sí.
  • Column Family: la información se guarda en columnas dentro de la keyspace, pero se agrupan en familias para identificar la separación entre un conjunto de datos y otro. Por lo tanto, dentro de las keyspace debemos de crear column families, lo que en las bases de datos tradicionales serían las tablas.
  • Columnas: son cada una de las columnas que se agrupan bajo una familia, que se declaran con un tipo (para validación del dato) y con un nombre. Si se establece un índice sobre la misma, entonces se da la posibilidad de poder buscar utilizándola.

Llegados a este punto, vemos diferencias con otras NoSQL, como por ejemplo Riak. Riak tiene buckets donde Cassandra tiene keyspaces. En Riak cada bucket almacena claves a las que se les asigna un valor… en Cassandra esto no existe, ya que la clave de Cassandra está un nivel más abajo, cuando ya se han definido las familias de columnas. Esto deja a Cassandra entre dos mundos.

Entre SQL y NoSQL… CQL

Para confirmarlo, Cassandra dispone de un lenguaje de consulta que hace posible el empleo del mismo para realizar búsquedas entre sus familias de columnas, sobre las columnas que se hayan definido (con índice, claro). Este lenguaje provee de las órdenes básicas para realizar inserciones, actualizaciones, eliminaciones y obtención de datos.

Es más, el lenguaje en sí es llamado CQL y, viendo su sintaxis se sabe el porqué de la similitud con SQL. Por ejemplo, si tenemos creada la familia de columnas contactos, con una columna llamada nombre, y otra telefono, podemos realizar la siguiente consulta:

SELECT nombre, telefono FROM contactos

En las nuevas versiones de Cassandra, además, se puede emplear, en lugar de cassandra-cli el nuevo cqlsh, que permite emplear los comandos en formato CQL para manejar el cluster y hacer consultas al mismo. Esto hace pensar que Cassandra se comienza a desplazar cada vez más hacia el modelo relacional, dejando el paradigma de clave-valor muy atrás.

No obstante, facilita el acceso a este tipo de base de datos, a sistemas tan potentes, como para mantener un conjunto de máquinas en activo, en un anillo balanceando peticiones y en modo maestro-maestro con cada nodo.

Conclusiones

Después de darle bastantes vueltas y emplearlo para un par de desarrollos, he encontrado Cassandra bastante potente para el desarrollo de aplicaciones en las que la información se mantiene estática y se puede capturar de forma fácil a través de sus claves. Es muy rápido dando la información y él mismo balancea entre los nodos que tenga configurado.

Una nota negativa puede ser el hecho de que la búsqueda de información se hace bastante dificultosa debido a que, los datos de las columnas tienen que estar prefijados y muchos datos, en el enlace con Thrift, no funcionan bien. Así mismo, el filtrado por cualquier campo obliga a crear un índice sobre ese campo, lo que conlleva más ocupación de espacio y ralentizar un poco las inserciones, modificaciones y eliminaciones.

En definitiva, es una base de datos con capacidad fácil para montarse en forma de cluster, que permite una rápida ingesta de datos (siempre que tengan un formato prefijado), y una consulta también rápida de los mismos. No es indicado para sistemas en los que las consultas se puedan complicar, ya que requiere en ese caso de la creación de muchos índices e incluso muchas tablas intermedias para no perder la pista de la información. Al final, la mayoría de código hay que ejecutarlo del lado del cliente, por lo que cuanto más difícil sea el esquema de datos, más lento se volverá.

]]> http://bosqueviejo.net/2012/04/25/cassandra-la-nosql-de-facebook/feed/ 0 Riak: revisando y practicando http://bosqueviejo.net/2012/04/24/riak-revisando-y-practicando/ http://bosqueviejo.net/2012/04/24/riak-revisando-y-practicando/#comments Tue, 24 Apr 2012 12:13:18 +0000 bombadil http://bosqueviejo.net/?p=1287 Después de la introducción que hice ya hace unos meses sobre la teoría en la que se fundamenta esta base de datos, me he dispuesto a someterla a unas pruebas de funcionamiento, para así aprender a manejar de forma apropiada esta herramienta.

En principio, como revisé solo los conceptos en los que se basa y no el funcionamiento a nivel de usuario, de programador, no sabía si era una interfaz amigable para realizar consultas o búsquedas, y la forma de realizar las cargas, inserciones y demás. Tengo que decir que, al menos el acceso y la comunicación con el servidor resulta muy cómoda y sencilla, ya que se basa en REST.

A través de peticiones HTTP muy sencillas y que se pueden generar incluso desde la línea de comandos con herramientas como curl, podemos realizar peticiones a la base de datos.

Mensajes hacia Riak

En principio, Riak se basa en REST, esto quiere decir que cada URI especifica un recurso dentro de la base de datos, y sobre ese recurso podemos realizar las acciones HTTP que se relacionan a cualquiera de las acciones básicas de una petición:

  • GET equivale a tomar datos, sería la R del CRUD (retrieve) o el SELECT del SQL.
  • PUT equivale a insertar datos nuevos, sería la C del CRUD (create) o el INSERT del SQL.
  • POST equivale a una modificación o actualización de datos, sería la U del CRUD (update) o el UPDATE de SQL.
  • DELETE equivale a una eliminación del dato, sería la D (delete) o el DELETE de SQL.

Esto permite muchas ventajas, como el uso, en el GET, de la cabecera If-Modified-Since, que nos dará la posibilidad de comprobar si un elemento pesado (imagen, vídeo o similar) es nuevo o no, para volver a descargarlo. Riak nos retornará el objeto con el mensaje 200 para indicar que hay uno nuevo, o solo la cabecera 304 (Not Modified) para indicarnos de que es el mismo que ya tenemos, por lo que no hace falta volver a transmitirlo.

Ante una petición de POST, o una de PUT en el que no exista el registro, se retornará el mensaje 201 (Created), y ante una operación de DELETE, si ha salido bien recibiremos un 204 (No Content) o 404 (Not Found).

Composición de la URI

La URI para localizar recursos dentro de Riak se puede establecer como sigue:

/riak/BUCKET/RESOURCE

NOTA: la palabra clave riak ha sido modificada en nuevas versiones por buckets, pero se mantiene riak por compatibilidad hacia atrás. Por lo que, si estás instalando una versión nueva tomada de la parte de descargas de Riak, puedes usar en lugar de riak la palabra buckets.

Riak configura su URI de modo que la primera palabra clave es precisamente riak, seguida por el bucket donde se almacenarán los recursos que se indique a continuación en la URI. El bucket es un bolsillo en el que se puede almacenar lo que se desee. Además, el bucket se puede configurar a través del paso de algunos parámetros de configuración específicos. Esto se sale un poco del objetivo del artículo, por lo que si tienes curiosidad de lo que se puede configurar puedes echarle un vistazo a este enlace.

Volviendo al tema, tenemos recursos. Estos recursos son un espacio en el que podemos guardar la información que necesitemos. Puede ser un texto normal, codificado como YAML, como JSON, como XML, o incluso una imagen o un vídeo… o incluso una imagen ISO (comprobado con una ISO de Sabayon de 700 MB aproximadamente).

Por lo que, podemos probar a hacer algunas prácticas. Lanzamos Riak. Si lo tenemos en ejecución en el puerto 8098 (es el de por defecto cuando se instala el paquete deb), podemos hacer lo siguiente:

curl -v -X PUT -H "Content-type: image/jpeg" --data-binary @imagen.jpg http://127.0.0.1:8098/riak/pruebas/imagen.jpg

Nota: asegúrate de que la localización de la imagen es correcta, a una imagen de tu disco válida, y no olvidas poner la arroba (@) justo antes de esa ruta (sin espacios).

La comprobación más simple es a través del cualquier navegador que tengas instalado en esa misma máquina:

http://127.0.0.1:8098/riak/pruebas/imagen.jpg

Con esto ya tendríamos la primera pureba satisfactoria de nuestro sistema de clave-valor para el almacenamiento de datos. Ahora, si lo que queremos es eliminarla, podemos hacerlo así:

curl -v -X DELETE http://127.0.0.1:8098/riak/pruebas/imagen.jpg

Si recargamos el navegador con la URL anterior, veremos que nos responde not found.

Búsquedas en Riak

En caso de que tengamos información formateada en JSON dentro de cada clave y queramos hacer una búsqueda de esta información para extraer únicamente las claves que nos sean útiles, tendremos que emplear el sistema conocido como map-reduce, para realizar una búsqueda a través de todas las claves de un bucket.

Voy a basarme en lo explicado en la documentación oficial de Riak, para no tener que inventar datos. En principio, si descargamos los dos siguientes ficheros y los ejecutamos:

  • goog.csv, datos a insertar en Riak (en formato CSV).
  • load_data, script en Erlang que insertará los datos, convirtiéndolos en un formato JSON. Hay que editar el scirpt y cambiar la URL para que tenga el puerto correcto, en mi caso puse 8098.

Esto nos da un bucket bastante grande en el que poder practicar.

Como decíamos antes, vamos a dar un repaso al sistema de MapReduce, el cual fue popularizado por Google. Este se basa en el algoritmo de divide y vencerás, realmente, ya que realiza un lanzamiento sobre cada elemento individual (map) tomando un resultado y, después, la parte de reduce, se encarga de analizar y unificarlo todo en un solo resultado.

Por lo tanto, tenemos que enviar mediante POST, a una URI concreta, un formato JSON de dato que será el siguiente:

{"inputs": "goog", "query": [
    {"map": {
        "language":"javascript",
        "source": "function(value, keyData, arg) { var data = Riak.mapValuesJson(value)[0]; if(data.High && parseFloat(data.High) > 600.00) return [value.key]; else return []; }",
        "keep": true
    }}
]}

Si guardamos esto en un fichero, podemos lanzarlo con el siguiente comando:

curl -X POST http://127.0.0.1:8098/mapred -H "Content-type: application/json" -d @mapred.json

En este caso, la función de map es la siguiente:

function(value, keyData, arg) {
  var data = Riak.mapValuesJson(value)[0];
  if(data.High && data.High > 600.00)
    return [value.key];
  else
    return [];
}

Esto quiere decir que se toma el contenido de cada clave, se parsea con una función especial de Riak para convertir de JSON y retornar la primera línea para que sea almacenada en data. Se comprueba que tenga campo High y que High sea mayor de 600.

Es un filtro como se puede hacer con cualquier función map en cualquier lenguaje (que disponga de ella, claro).

Ahora, para emplear tanto map, como reduce, imagina que lo que queremos, de esta información, es econtrar la máxima varianza diaria del precio por mes. Para eso, en el map sacaríamos la varianza diaria, y en el reduce tomaríamos solo la máxima varianza por mes, las funciones serían así:

/* Map calcula la varianza diaria y asigna la clave por mes */
function(value, keyData, arg){
  var data = Riak.mapValuesJson(value)[0];
  var month = value.key.split('-').slice(0,2).join('-');
  var obj = {};
  obj[month] = data.High - data.Low;
  return [ obj ];
}
 
/* Reduce encuentra la varianza máxima por mes */
function(values, arg){
  return [ values.reduce(function(acc, item){
             for(var month in item){
                 if(acc[month]) { acc[month] = (acc[month] < item[month]) ? item[month] : acc[month]; }
                 else { acc[month] = item[month]; }
             }
             return acc;
            })
         ];
}

Codificado para enviarlo en el fichero mapred.json, lo anterior quedaría así:

{"inputs":"goog",
 "query":[{"map":{"language":"javascript",
                  "source":"function(value, keyData, arg){ var data = Riak.mapValuesJson(value)[0]; var month = value.key.split('-').slice(0,2).join('-'); var obj = {}; obj[month] = data.High - data.Low; return [ obj ];}"}},
         {"reduce":{"language":"javascript",
                    "source":"function(values, arg){ return [ values.reduce(function(acc, item){ for(var month in item){ if(acc[month]) { acc[month] = (acc[month] < item[month]) ? item[month] : acc[month]; } else { acc[month] = item[month]; } } return acc;  }) ];}",
                    "keep":true}}
         ]
}

NOTA: el parámetro keep es el que nos dice qué es lo que se retorna. Si agregamos este mismo parámetro en las dos secciones (map y reduce), nos encontramos que el retorno de la búsqueda es tanto de uno como de otro.

Otras cosas

Otra de las cosas que han agregado es la posibilidad de enlazar recursos, de modo que, asignando un enlace y una etiqueta (con el nombre del tipo de enlace), podamos tener relacionado un recurso con otro. Esto da un abanico de posibilidades tan grande como el que se consigue con las bases de datos relacionales, ya que es posible tener en un bucket contactos, en otro datos específicos de un servicio y relacionar el contacto con esos datos agregando una etiqueta al mismo, e incluso que el enlace sea bidireccional agregando las etiquetas en los dos sentidos, cambiando la etiqueta para que sea semántica.

Una imagen de lo que se puede conseguir:

Las partes de administración (para ajustar las variables del teorema CAP) y configuración de otros nodos es algo que dejamos a revisar de la documentación oficial.

Conclusiones

Como puede verse, Riak solventa con su paradigma de NoSQL, basado en el almacenamiento por clave-valor y búsquedas por MapReduce, la mayoría de necesidades que se pueden encontrar a la hora de emplear este tipo de sistemas. Lo único que queda un poco en el aire, o hay que realizar con llamadas sucesivas, son las actualizaciones y eliminaciones masivas, pero realmente, puede ser un mal menor, si estas no son empleadas en el esquema que se vaya a implementar Riak.

Hay que tener presente que Riak es una muy buena base de datos, que fundamenta sus potencias en la posibilidad de contar con un cluster, lecturas rápidas con caché, y búsquedas artificiosas con MapReduce, pero puede haber otros usos en los que las consultas de modificación y eliminación masivas sean lo más importante y esto ya sería mejor abarcarlo con otra base de datos de otro tipo.

]]> http://bosqueviejo.net/2012/04/24/riak-revisando-y-practicando/feed/ 0 No, Erlang no es eso http://bosqueviejo.net/2012/04/18/no-erlang-no-es-eso/ http://bosqueviejo.net/2012/04/18/no-erlang-no-es-eso/#comments Wed, 18 Apr 2012 11:45:39 +0000 bombadil http://bosqueviejo.net/?p=1340 Vale, después de leer varios artículos que llevan a lo mismo, intentar meter la orientación a objetos en Erlang (y como estos otros ejemplos más que no citaré de momento).

Si pensamos lo que Alan Kay decía sobre la orientación a objetos, no se refería a tener un espacio en la memoria en la que albergar datos que pudiesen ser modificados a través de llamadas a funciones. Él definía de manera conceptual la instancia de un objeto, vivo, al que se le pasan mensajes para trabajar con esa información y retornar una respuesta. ¿No es más parecido a lo que se puede hacer con un gen_server, por ejemplo?

También hay gente que intenta hacer que los procesos de Erlang sean más eficientes que los de otros lenguajes y, sino lo son, Erlang no sirve… cuando, creo que está claro o sino es mejor repasarlo… que Erlang no destaca por la velocidad de sus procesos, sino por la versatilidad de poder crear millones de ellos e incluso a través de un cluster, de modo que se facilita la computación distribuida, no solo la concurrente.

Entonces, ¿cuál es realmente el fallo de que la gente piense en cosas como orientación a objetos o rendimiento de los procesos? … que no han entendido el cambio de paradigma.

Programación Orientada a la Concurrencia

El paradigma que ofrece Erlang, y que está ofreciendo Go, y que se ofrece a través de Celluloid en Ruby, y otros muchos frameworks en otros diversos lenguajes, es lo que se conoce como Modelo Actor, o a mi me gusta llamar Programación orientada a la Concurrencia.

La programación orientada a la concurrencia se basa en los procesos, que son la unidad mínima de computación para concurrencia en este paradigma. Un proceso se define a través de un módulo y puede ser lanzado una o varias veces, dependiendo de la cantidad de procesos que puedan existir en ejecución para un programa específico.

El proceso es en este paradigma lo que el objeto en el paradigma de la orientación a objetos, teniendo un espacio de memoria (heap) en el que almacena datos privados y que él solo puede manipular, y la posibilidad de recibir mensajes para realizar acciones concretas retornando, o no, un valor. En este sentido, agregamos la posibilidad, porque de concurrencia hablamos, de llamadas síncronas o asíncronas.

Como cada proceso, es una entidad de memoria que almacena datos y que responde a la ejecución de código, se puede especificar con un diagrama de clases UML este diseño, teniendo presente la cardinalidad para la existencia de 1 a N posibles instancias de procesos.

Además, a través de los comportamientos, Erlang nos permite crear entidades avanzadas como supervisores, máquinas de estados y generadores de eventos. Estas entidades facilitan enormemente el trabajo de programación de entidades que antes, en el paradigma de objetos, eran impensables.

Diseñar una web en la que se emplea un controlador a través de una máquina de estados para hacer un sistema statefull que mantiene la sesión en memoria sin necesidad de serializar/deserializar información. Además de, en caso de necesitar enviar información a un log o una inserción demorada (sea cual sea la base de datos), es algo que tan solo se puede hacer a través de programación paralela.

Por otro lado, la optimización. El cómputo del coste algorítmico queda totalmente desfasado, realmente. En un servidor de cuádruple núcleo con dos procesadores (16 en total), un algoritmo que se ejecuta de forma distribuida, además, en dos instancias una en cada servidor como el mencionado, tiene la posibilidad de ejecutarse 32 veces más rápido que un programa escrito de forma secuencial o empleando hilos (que normalmente no emplean varias CPUs).

¿Ahora sí?

En esencia. Esto es como cuando salió GTK para PHP, si PHP no está diseñado para estar más de 15 minutos en ejecución (porque se suele bloquear y tiene siempre algún que otro leak de memoria), ¿por qué intentamos introducir orientación a objetos en un lenguaje funcional cuando la metodología más idónea es la orientación a la concurrencia (o el modelo actor)? Acepto comentarios que lo aclaren (si es que esto es posible :-D ).

]]> http://bosqueviejo.net/2012/04/18/no-erlang-no-es-eso/feed/ 0 Go: El lenguaje de Google http://bosqueviejo.net/2012/04/10/go-el-lenguaje-de-google/ http://bosqueviejo.net/2012/04/10/go-el-lenguaje-de-google/#comments Tue, 10 Apr 2012 17:32:54 +0000 bombadil http://bosqueviejo.net/?p=1314 Hace un par de años que escuché que Google trabajaba en un lenguaje, y hace poco que ya había visto la luz una versión estable, la primera.

Hay personas que me han comentado que Go era parecido a Erlang, que Go hacía concurrencia de forma muy simple, y que Go es un lenguaje muy a tener en cuenta y presente, sobretodo en terreno de concurrencia y escalabilidad. Hoy le he dedicado un par de horas a revisar la documentación y a programar un poco y ver cómo se programa en Go, las potencias que tiene el lenguaje según sus creadores (y lo que han podido introducir a lo largo del tutorial y el manual).

En 2007, un diseño inicial de Go fue comenzado por Robert Griesemer, junto a Rob Pike (creador del lenguaje Limbo) y Ken Thompson (uno de los creadores del lenguaje C y Unix), todos ellos bajo el seno de Google, donde los tres trabajan actualmente, por lo que, de momento, por su historia, promete.

Revisión del lenguaje

En principio, Go es un lenguaje tipado y fuertemente tipado. Tiene auto-detección de tipos para no tener que escribir mucho y han organizado su declaración de modo que resulta un poco extraño para quien haya programado en C y Java, por ejemplo. Mientras que un código en estos lenguajes declara el tipo y modificadores para después indicar el nombre de la variable, Go lo hace al revés. Se indica primero el nombre de las variables y después el tipo. Además, el tipo puede tomarse de forma intrínseca si se hace una inicialización con un valor. Por ejemplo:

var x int  // declaración simple
var y, z int  // declaración múltiple, ambas serán int
var a := 1  // declaración intrínseca a int
var a, b := 1, 2 // declaración intrínseca de a y b a int

En este aspecto, recuerda bastante a Python, pudiendo hacer asignación múltiple en una misma línea. La palabra var es necesaria en la declaración de las variables de modo global, y solo opcional dentro de las funciones. Un dato de tipo intrínseco dentro de las funciones, a menos que se emplee var, debe de indicarse con el operador :=

La declaración de funciones se realiza con la palabra clave func, pudiendo aceptar parámetros tipados de la misma forma que la declaración de variables. El retorno, al igual que la asignación, se realiza de modo que se puedan retornar varios valores, igualmente, otro parecido más a Python en este sentido:

func add( x, y int ) int {
    return x + y
}

En parecido con C, para que el código sea ejecutado, debe de existir una función main.

Como estructuras de control, tenemos if, for y switch. El bucle while se puede simular a través del uso simplificado de for, que permite eliminar la parte de inicialización y actualización para realizar son la condición de bucle. Igualmente, si no se indican ninguna de las tres, se realiza un bucle infinito.

for i := 1; i<10; i++ {
    // bucle for normal
}
 
for i < 10 {
    // simulación de while
}
 
for {
    // bucle infinito
}

Las estructuras if permiten el uso de la parte de inicialización, como si se tratase de un bucle for, y las estructuras switch permiten declarar comparadores, no solo valores estáticos como en Java, C, PHP y otros, además de también el bloque de inicialización como if:

if i == 10 {
    // if normal
}
 
if i=10; i==10 {
    // if con inicialización
}
 
switch i=10; i {
    case 1: // si es 1
    case 2: // si es 2
    case 10: // aqui entra
    default: // por defecto
}
 
switch {
    case i == 1: // si es 1
    case i == 2: // si es 2
    case i > 3: // aqui entra
    default: // por defecto
}

La organización de las estructuras de datos se puede hacer mediante struct, al igual que en C, e incluso se pueden definir funciones que trabajen como si uno de sus parámetros intrínsecos fuese un struct. Con esto se puede simular el uso de los métodos, pero queda muy lejos de lo que respecta a la programación orientada a objetos.

Se pueden ver más ejemplos en tutorial de Go (en inglés).

Potencias del lenguaje

Revisándolo a fondo, veo que la tendencia de los lenguajes de tipado estático comienza a estar de moda, tienen sus ventajas ya que permiten cazar fallos en tiempo de compilación (cuando no hay inferencia de tipos, claro). En este caso esa cualidad es bastante evidente, así como que el código pueda compilarse de forma nativa como hace también Opa.

La concurrencia que emplea Go se parece bastante a Erlang en base en que es por paso de mensajes. La única diferencia radica en que el buzón para el paso de mensajes se debe de crear. Go nomina sus buzones como canales de comunicación. Un símil muy aproximado a los sockets Unix, ya que se establecen como recursos independientes y se pueden emplear en cualquier proceso y en cualquier momento.

Conclusiones

El lenguaje Go es un lenguaje que ha nacido con un propósito claro, según sus objetivos entre los que se encuentran: seguridad (de tipos y de memoria), buen soporte de concurrencia y comunicación, eficiencia en la recolección de basura (sin latencias) y alta velocidad de compilación.

Viniendo de dos de los trabajadores de los laboratorios Bell que contribuyeron a lenguajes como Limbo, C, BPEL, etc. y estando en el seno de Google, el futuro de este lenguaje se ve muy prometedor.

Este lenguaje permite la programación orientada a la concurrencia o modelo actor, con lo que, la orientación a objetos, realmente, no es una característica que se eche en falta, ni mucho menos, siempre teniendo presente que el paradigma de programación al que se orienta no son los objetos, en su núcleo central, sino los procesos (o hilos).

Cabe destacar que el uso de la memoria compartida es un hecho ya que el comando go lo que hace es lanzar, como dice el tutorial goroutines, que a nivel interno son hilos, por lo que comparte el mismo heap de memoria y puede llegar a ser un problema en el uso de la concurrencia y el modelo actor propiamente dicho.

Por otro lado, carece de estructuras que faciliten el uso de monitores de hilos a modo de que cuando uno muera se notifique este hecho a otro y poder construir estructuras como las de los supervisores.

Veremos como va progresando a lo largo de las siguientes liberaciones, de momento son buenos pasos los que ha dado el pequeño, y con la promesa de Google de mantener la sintaxis y compatibilidad en sus futuras versiones, es una seguridad de cara a programar y no tener que refactorizar al cambiar a una nueva versión.

]]> http://bosqueviejo.net/2012/04/10/go-el-lenguaje-de-google/feed/ 2 Erlang: Servidores Concurrentes TCP http://bosqueviejo.net/2012/04/09/erlang-servidores-concurrentes-tcp/ http://bosqueviejo.net/2012/04/09/erlang-servidores-concurrentes-tcp/#comments Mon, 09 Apr 2012 10:43:10 +0000 bombadil http://bosqueviejo.net/?p=1270 Para la programación de elementos que requieran concurrencia, Erlang, es una de las mejores elecciones que se puede tomar. El hecho de construir servidores UDP con los mecanismos que nos ofrece OTP es algo trivial, muy simple de conseguir, tal y como se puede ver en este otro artículo, pero la cosa se complica, cuando lo que queremos obtener es una conexión, o un conjunto de conexiones concurrentes para TCP.

Para comenzar, vamos a poner de nuevo de manifiesto la plantilla del gen_server, si se quieren tener más referencias sobre el gen_server se puede consultar este otro artículo, o de forma más extensa en este artículo del Blog Aprendiendo Erlang.

Por lo tanto, la estructura de un código con gen_server es la siguiente:

-module(server).
-author('bombadil@bosqueviejo.net').
 
-behaviour(gen_server).
 
-define(SERVER, ?MODULE).
 
-export([start_link/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
         terminate/2, code_change/3]).
 
-record(state, {}).
 
start_link() ->
    gen_server:start_link({local, ?SERVER}, ?MODULE, [], []).
 
init([]) ->
    {ok, #state{}}.
 
handle_call(_Request, _From, State) ->
    Reply = ok,
    {reply, Reply, State}.
 
handle_cast(_Msg, State) ->
    {noreply, State}.
 
handle_info(_Info, State) ->
    {noreply, State}.
 
terminate(_Reason, _State) ->
    ok.
 
code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

Agregando conexiones TCP

TCP, a diferencia de UDP, necesita formalizar que está escuchando en un nodo, y aceptar cada petición entrante para mantener una comunicación bilateral. En este caso, el init se complica. Debemos de establecer la escucha del puerto y esto requiere de que pasemos algunos parámetro y opciones:

-record(state, {lsocket, socket}).
 
init([]) ->
    Opts = [binary, {packet, 0}, {active, true}],
    case gen_tcp:listen(5000, Opts) of
        {ok, LSocket} ->
            {ok, #state{lsocket = LSocket}, 0};
        {error, Reason} ->
            {stop, Reason}
    end.

Para esto, tendremos que agregar el parámetro lsocket y socket al registro de estado.

La función init se encarga de establecer la escucha en el puerto 5000, de forma activa. Para más opciones se puede revisar tanto la documentación de gen_tcp, como las opciones específicas disponibles en el paquete inet a través de setops.

Como se puede ver, en caso de que la escucha se establezca de forma apropiada, hay un timeout configurado a cero, por lo que, se llamará al callback de handle_info, con el parámetro timeout. En ese punto, es donde tenemos que agregar la parte del servidor TCP en la que se espera por una conexión entrante para poder atenderla. La función, por tanto, sería:

handle_info(timeout, State=#state{lsocket=LSocket}) ->
    {ok, Socket} = gen_tcp:accept(LSocket),
    {noreply, State#state{socket=Socket}};
 
handle_info(Info, State=#state{socket=Socket}) ->
    io:format("~p~n", [Info]),
    gen_tcp:send(Socket, io_lib:format("~p~n", [{date(),time()}])),
    gen_tcp:close(Socket),
    {noreply, State, 0}.

El programa es algo simple, ya que acepta la conexión, espera una transmisión y responde enviando la fecha y hora y cierra la conexión. Podemos probarlo de la siguiente forma:

$ nc localhost 5000
hola
{{2012,4,4},{20,5,49}}

Y ahora… la concurrencia

Como puedes observar, mientras tienes abierta la primera conexión, la segunda no se establece porque el sistema está ocupado con la primera petición. Esto conlleva un cuello de botella, ya que la concurrencia es nula.

Para conseguir ampliar la concurrencia, desde el primer servidor, el proceso que tiene en escucha el puerto, debe de lanzar un proceso, un nuevo servidor para atender cada petición de forma independiente.

Para esto necesitamos crear otro nuevo gen_server, pero con unas características diferentes, ya que no se mantendrá a la espera de conexiones entrantes, sino que será para manejar una conexión activa.

El módulo gen_tcp nos ayuda en esta tarea, ya que cada mensaje entrante lo recibimos a través de handle_info en el proceso padre, como habíamos visto antes, y esto debemos de redireccionarlo hacia el proceso hijo que creemos. En principio, copiando la estructura de gen_server de nuevo y llamándola request, agregamos un par de cambios como el siguiente:

start_link(Socket) ->
    {ok, Pid} = gen_server:start_link(?MODULE, [Socket], []),
    gen_tcp:controlling_process(Socket,Pid),
    inet:setopts(Socket, [{active, once}]),
    {ok, Pid}.

Esta forma de lanzar el gen_server, hace que el proceso no tenga un nombre asociado, por lo que se pueden lanzar tantos como queramos o necesitemos. Para el gen_tcp, indicamos que el proceso que atenderá las peticiones de ese socket será el que se acaba de crear, y se le indica que puede enviar una petición.

La función de inicialización tendrá esta forma:

-record(state, {socket}).
 
init([Socket]) ->
    {ok, #state{socket=Socket}}.

En el módulo server podemos eliminar la parte de gestión de la petición (la parte de handle_info que se refiere estrictamente a la gestión de la petición) y dejar solo la parte de la aceptación de la petición de esta forma:

handle_info(timeout, State=#state{lsocket=LSocket}) ->
    {ok, Socket} = gen_tcp:accept(LSocket),
    request:start_link(Socket),
    {noreply, State, 0}.

En el nuevo módulo request, agregamos la parte de código que se encarga de realizar la contestación:

handle_info(Info, State=#state{socket=Socket}) ->
    io:format("~p~n", [Info]),
    gen_tcp:send(Socket, io_lib:format("~p~n", [{date(),time()}])),
    gen_tcp:close(Socket),
    {stop, normal, State}.

En este caso, cuando gen_tcp envía un mensaje desde el cliente al servidor, este mensaje disparará la ejecución de esta función, imprimirá por pantalla el mensaje recibido, contestará de forma fija con la fecha y hora actual, cerrará la conexión con el cliente y detendrá la ejecución del proceso.

Algunas pruebas

Si ejecutamos en una máquina virtual de Erlang el servidor, y abrimos dos consolas o tres o más con el siguiente comando:

$ nc localhost 5000

Veremos que todas y cada una de las consolas obtienen conexión y quedan en el proceso hijo a la espera de un mensaje que envíes. Puedes poner el texto que quieras y presionar el retorno de carro. Volviendo a la consola de Erlang, se verá el mensaje escrito en cada una de las consolas.

Si modificamos el código para que acepte paquetes de tipo http y procesamos una respuesta válida, podemos probar la carga a través de programas como wrk o ab. En mis pruebas, he conseguido:

$ ab -n 10000 -c 50 http://127.0.0.1:5000/
[...]
Concurrency Level:      50
Time taken for tests:   0.885 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      760000 bytes
HTML transferred:       110000 bytes
Requests per second:    11303.38 [#/sec] (mean)
Time per request:       4.423 [ms] (mean)
Time per request:       0.088 [ms] (mean, across all concurrent requests)
Transfer rate:          838.92 [Kbytes/sec] received

Una tasa de unas 11 mil peticiones por segundo. Nada mal.

]]> http://bosqueviejo.net/2012/04/09/erlang-servidores-concurrentes-tcp/feed/ 0 Clean Code: para ser mejor programador http://bosqueviejo.net/2012/04/03/clean-code-para-ser-mejor-programador/ http://bosqueviejo.net/2012/04/03/clean-code-para-ser-mejor-programador/#comments Tue, 03 Apr 2012 08:21:51 +0000 bombadil http://bosqueviejo.net/?p=1294 Dando un repaso a mi biblioteca he vuelto a topar con un libro que me llamó la atención antaño, leí aunque muy por encima y, hoy dándole otro repaso he pensado, ¡qué razón tiene!

El libro se llama Clean Code es de Robert C. Martin, e intenta arrojar un poco de luz sobre el hecho de programar mejor, o como su título indica, hacer el código más claro, más limpio.

Una de las frases iniciales es (al pie de la imagen que he empleado para este artículo): Estás leyendo este libro por dos motivos. El primero es que eres programador. El segundo, quieres ser mejor programador. Hace mención a la clave de todo buen programa: que sea pequeño; algo que la filosofía de Unix nos dejó claro en su enunciado: hacer programas que solo hagan una cosa, pero que la hagan muy bien.

También comenta un problema que surgió, una experiencia personal, en la que desarrollaron una killer app, que todo el mundo quería, se vendió muy bien y comenzó a crecer, más características, pero también más fallos. El crecimiento fue descontrolado y el código empezó a ser cada vez peor. Esto llevó a la empresa a la quiebra.

En este sentido, podemos incluso ver un gráfico de productividad frente a tiempo cuando el código es desordenado y malo:

Cuanto más aumenta el tiempo de desarrollo del software, más cuesta agregar nuevas funcionalidades.

Seguro que ahora se nos vendrán a la cabeza muchos casos vividos acerca de este hecho, muchas vivencias incluso, código heredado que hemos tenido que mantener, reescribir e incluso nuestro propio código después, haberlo tenido que reescribir igualmente porque, erróneamente, seguimos los principios equivocados.

Las claves para escribir buen código, o código limpio y claro, se relatan en este libro, el cual se hace bastante ameno y en algunos puntos bastante divertido, e incluso revelador. Podemos citar algunos de esos puntos, aunque en modo esquemático:

  • Cuestión de actitud, obviamente, si consideras que el código bien hecho es inviable para tu día a día, ese el primer punto que deberías de cambiar, ya que no te estás dando cuenta de que, cuanto más barro echas encima, más lento te desplazas.
  • Refactorizar debe de ser una tarea cotidiana o al menos parte del desarrollo de una nueva característica, ya que cuando se introduce nuevo código, cambios o correcciones, muchas veces conviene dar un repaso a todo el código y rehacer algunas partes que puedan no tener sentido… o incluso borrar otras que ya no se usen, para no dificultar la lectura de código que está muerto.

Como decía Bjarne Stroustrup: Me gusta que mi código sea elegante y eficiente. La lógica debe ser directa, clara, para que a los fallos les sea difícil esconderse, las dependencias mínimas para facilitar el mantenimiento, el manejo de errores completo acorde a una estrategia planificada y el rendimiento muy próximo a óptimo para no tentar a la gente a hacer código desordenado con optimizaciones sin base alguna. El código limpio y claro hace las cosas bien.

Hay más comentarios de Grady Booch, Dave Thomas, Michael Feathers, Ron Jeffries y Ward Cunningham. Todos ellos comentando y/o definiendo lo que significa, para ellos, el código limpio.

El libro es muy recomendable, por su contenido, por sus enseñanzas y por ver la forma de progresar y hacer código que tenga un tiempo de mantenimiento mayor, es decir, que sea fácil de mantener, extender y corregir.

]]> http://bosqueviejo.net/2012/04/03/clean-code-para-ser-mejor-programador/feed/ 0 Erlang: Servidores UDP http://bosqueviejo.net/2012/03/21/erlang-servidores-udp/ http://bosqueviejo.net/2012/03/21/erlang-servidores-udp/#comments Wed, 21 Mar 2012 10:03:23 +0000 bombadil http://bosqueviejo.net/?p=1274 Una de las grandes potencias de Erlang es su capacidad para construir servidores. A través de OTP, esta tarea se convierte en algo tan sencillo, que asombra ver con qué pocas líneas de código se crea un servidor.

En este caso vamos a montar un servidor UDP. Esto lo revisé en su día porque estuve realizando un pequeño servidor para el protocolo syslog, de lo que resultó este servidor, que permite pasar a través de un manejador de eventos (gen_event) los mensajes de syslog recibidos a través del puerto 514 en formato UDP.

En principio, comentaré un poco la estructura del comportamiento (behaviour) de Erlang/OTP que emplearemos: gen_server.

Empleando los gen_server

El gen_server es el comportamiento más básico que se encuentra disponible en OTP, ya que sobre él se construyen otros como gen_fsm. Este comportamiento específico se fundamenta en la recepción de mensajes y su manejo a través de unos callbacks, de modo que tenemos tres tipos de mensajes que podemos procesar:

  • call: referidos a llamadas en las que se envía una petición y se espera por una respuesta del servidor. Siendo realizadas desde otros procesos de Erlang.
  • cast: estas son llamadas que se envían y no se espera por una respuesta. También son realizadas desde otros procesos de Erlang.
  • info: este podría considerarse un comodín, ya que en esta categoría entran todos los mensajes que no entran en las anteriores. Normalmente, aquí es donde recibiremos la información UDP y TCP de los servidores que creemos de cara a la red.

La estructura de un código con gen_server es la siguiente:

-module(server).
-author('bombadil@bosqueviejo.net').
 
-behaviour(gen_server).
 
-define(SERVER, ?MODULE).
 
-export([start_link/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
         terminate/2, code_change/3]).
 
-record(state, {}).
 
start_link() ->
    gen_server:start_link({local, ?SERVER}, ?MODULE, [], []).
 
init([]) ->
    {ok, #state{}}.
 
handle_call(_Request, _From, State) ->
    Reply = ok,
    {reply, Reply, State}.
 
handle_cast(_Msg, State) ->
    {noreply, State}.
 
handle_info(_Info, State) ->
    {noreply, State}.
 
terminate(_Reason, _State) ->
    ok.
 
code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

Si guardamos esta estructura como server.erl (que es el nombre del módulo, tal y como se indica en la primera línea), el sistema compilará y lo podremos incluso lanzar con el comando:

server:start_link().

Convirtiendo nuestro gen_server en servidor UDP

Para convertir nuestro gen_server en un servidor UDP solo necesitamos abrir en escucha el puerto que queramos en modo UDP a través de gen_udp y el resto lo hará la estructura gen_server. Sería tan simple como modificar la función init para que albergase el siguiente código:

init([]) ->
    Port = 5000,
    {ok, Socket} = gen_udp:open(Port),
    error_logger:info_msg("Listen in port ~p~n", [Port]),
    {ok, #state{socket=Socket}}.

Y también la estructura del registro de estado, para albergar la información que necesitamos almacenar en el proceso, que será el recurso del puerto abierto:

-record(state, {socket}).

Es bueno que, además, agregemos en el terminate la cláusula que nos permita cerrar el servidor UDP, esto lo podemos agregar modificando la función termiante de la siguiente forma:

terminate(_Reason, State) ->
    gen_udp:close(State#state.socket),
    ok.

Por último, vamos a hacer que cada mensaje que nos llegue desde el servidor UDP se presente a modo de log en la consola. Esto lo haremos modificando la función handle_info, que como habíamos visto antes, es la que recibe los mensajes UDP:

handle_info(Info, State) ->
    error_logger:info_msg("Received via INFO: ~p~n", [Info]),
    {noreply, State}.

Probando el servidor

Para probarlo, solo tenemos que ejecutar en una consola:

$ erl 
Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [kernel-poll:false]
 
Eshell V5.9  (abort with ^G)
1> server:start_link().
 
=INFO REPORT==== 21-Mar-2012::10:52:44 ===
Listen in port 5000
{ok,<0.34.0>}

Abrimos otra consola, y ejecutamos el siguiente comando para generar un paquete UDP:

$ nc -u localhost 5000
hola

NOTA: tras escribir hola hay que presionar el retorno de carro (enter o intro) para que el paquete sea enviado.

Esto generará en la consola de Erlang el siguiente mensaje:

=INFO REPORT==== 21-Mar-2012::10:54:01 ===
Received via INFO: {udp,#Port<0.506>,{127,0,0,1},36772,"hola\n"}

Empleando el match en la función handle_info e incluso con expresiones regulares o lo que queramos, podremos tratar de forma más adecuada el mensaje.

Un ejemplo de aplicación de este servidor, como comenté al principio, se puede ver en este proyecto que comencé hace tiempo, un servidor de syslog, que se basa en la recepción de mensajes por el puerto UDP 514, y el envío, a través de gen_event de los mensajes recibidos.

Conclusiones

Con este ejemplo, Erlang demuestra que es muy fácil construir servidores de red, con muy pocas líneas de código. En este ejemplo, el hecho de ser un servidor UDP permite eliminar el payload de la escucha, aceptación y mantenimiento de conexión con el destinatario, simplemente se acepta el mensaje, se lee y procesa, muy simple y con un buen rendimiento del sistema.

]]> http://bosqueviejo.net/2012/03/21/erlang-servidores-udp/feed/ 4