En los títulos y los textos vais a encontrar unas cuantas citaciones cinematográficas (y si, soy un cinéfilo). Si no os interesan podéis fingir no verlas, ya que no son fundamentales para la comprensión de los post...

Este blog es la versión en Español de mi blog en Italiano L'arte della programmazione in C. Espero que mis traducciones sean comprensibles...

sábado, 17 de febrero de 2018

The Test Connection
cómo testear la conectividad en C

La Test Connection de este post es un poco menos peligrosa que la French Connection de la cual habla la obra maestra de W.Friedkin. Pero sigue siendo una actividad muy importante en algunos tipos de aplicaciones, entonces ni hablar de subestimarla.
...caras de conectividad avanzada...
Cuando utilizamos un computer interactivamente y queremos verificar el estado de la red, tenemos muchas formas sencillas de hacerlo: por ejemplo, con un buen ping a google.com sabemos si estamos conectados a Internet y, si no funciona, podemos utilizar algunas utilidades del sistema para averiguar lo que esta mal. Supongamos, sin embargo, tener que desarrollar una aplicación para un sistema embedded (¿somos o no somos programadores C?) y esta aplicación está conectada a la red y, en el caso de que no haya comunicación, debe informar de alguna manera (yo que se, encender un led error, ¡ciertamente no enviando un mensaje en la red!). Ok, y... ¿cómo lo hacemos? Veamos, ¡vamos con el código!
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <ifaddrs.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <linux/ethtool.h>
#include <linux/sockios.h>
#include <arpa/inet.h>

int main(int argc, char *argv[])
{
    int sock;

    // test interfaces
    //

    // get de todos los network devices configurados
    struct ifaddrs *addrs;
    getifaddrs(&addrs);

    // loop sobre los network devices configurados
    int i_alr = 0;
    struct ifaddrs *tmpaddrs = addrs;
    while (tmpaddrs) {
        // test interface
        if (tmpaddrs->ifa_addr && tmpaddrs->ifa_addr->sa_family == AF_PACKET) {
            // abre un socket para el test
            if ((sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) {
                // enseña error y continua
                printf("test interfaces: error socket para la interface %s: %s\n",
                       tmpaddrs->ifa_name, strerror(errno));
                continue;
            }

            // prepara los dati para ioctl()
            struct ethtool_value edata;
            edata.cmd = ETHTOOL_GLINK;
            struct ifreq ifr;
            strncpy(ifr.ifr_name, tmpaddrs->ifa_name, sizeof(ifr.ifr_name) - 1);
            ifr.ifr_data = (char *)&edata;

            // esegue ioctl()
            if (ioctl(sock, SIOCETHTOOL, &ifr) == -1) {
                // error ioctl: cierra el socket y continua
                printf("test interfaces: error ioctl para la interface %s: %s\n",
                       tmpaddrs->ifa_name, strerror(errno));
                close(sock);
                continue;
            }

            // enseña los resultados y cierra el socket
            printf("test interfaces: interface %s: %s\n",
                   tmpaddrs->ifa_name, edata.data ? "OK" : "NOK");
            close(sock);
        }

        // pasa al proximo device
        tmpaddrs = tmpaddrs->ifa_next;
    }

    // libera la devices list
    freeifaddrs(addrs);

    // test conectividad
    //

    // abre un socket para el test
    if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
        // error socket
        printf("test de conectividad: socket error: %s\n", strerror(errno));
        return EXIT_FAILURE;
    }

    // set de un timeout para send() (en este caso en realidad lo usa connect()) para evitar
    // un bloqueo sobre error de conexion)
    struct timeval tv;
    tv.tv_sec  = 1;     // set timeout en segundos
    tv.tv_usec = 0;     // set timeout en usegundos
    if (setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char*)&tv, sizeof(tv)) < 0) {
        // error ioctl
        printf("test de conectividad: setsockopt error: %s\n", strerror(errno));
        close(sock);
        return EXIT_FAILURE;
    }

    // NOTE: alternativa (non portable) a el uso de SO_SNDTIMEO:
    //int syn_retries = 1;     // send de un total de 1 SYN packets => timeout ~2s
    //if (setsockopt(sock, IPPROTO_TCP, TCP_SYNCNT, &syn_retries, sizeof(syn_retries)) < 0) {
    //  ...

    // prepara la estructura sockaddr_in para el server remoto
    struct sockaddr_in server;                  // server (remoto) socket info
    memset(&server, 0, sizeof(server));
    server.sin_family = AF_INET;                // set familia direcciones
    server.sin_addr.s_addr = inet_addr("216.58.214.174");   // set direccion server
    server.sin_port = htons(80);                // set numero port server

    // conexion al server remoto
    if (connect(sock, (struct sockaddr *)&server, sizeof(server)) < 0) {
        // error connect
        printf("test de conectividad: error connect: %s\n", strerror(errno));
        close(sock);
        return EXIT_FAILURE;
    }

    // enseña los resultados ed esce
    printf("test de conectividad: conectividad OK\n");
    close(sock);
    return EXIT_SUCCESS;
}
una premisa: este código está destinado a aplicaciones Linux Embedded, por lo que todo lo que sigue se refiere a un entorno Linux (bueno, como siempre, y es inútil explicar otra vez el tema...). El código es ampliamente comentado, así que no tengo que escribir demasiadas explicaciones. En este ejemplo, el código de test se escribe directamente en el main() pero, en un proyecto real, debería transformarse en una función que se puede llamar periódicamente en la posición más adecuada, tal vez directamente en el main() de la aplicación. Dado el tipo de prueba que se realiza, se debe llamar ocasionalmente, en función de cuanto de inmediata debe ser la señal de alarma que necesitamos. Normalmente, el uso es de baja frecuencia (hablamos de segundos, no de milisegundos), de lo contrario, nuestra función consumiría mucho tiempo de CPU solo para verificar la conectividad (y este no parece ser el caso).

el test se lleva a cabo en dos fases: test de las interfaces de red y test de conectividad. La primera comprueba eventuales problemas, digamos, Hardware: si tengo una conexión WiFi y una Ethernet en la misma máquina podría tener una conexión a Internet incluso si, por ejemplo, el cable de red está desconectado, y me interesa informar de esta situación, por lo que un único test de conexión no sería suficiente. La segunda fase verifica la conectividad real y, en caso de que falte, podemos saber si no hay conectividad a pesar de que las interfaces de red están bien conectadas, así de aislar mejor las posibles causas (en resumen, es un test bastante completo, pero se puede sofisticar aun más).

La fase de test de las interfaces se realiza con una función (relativamente nueva) de la siempre indispensable (en casos como este) ioctl(). Gracias a la función SIOCETHTOOL podemos verificar el funcionamiento de bajo nivel de cada interfaz, ya que nuestro código incluye un loop con el que analizamos todas las interfaces que, normalmente, son dos (loopback y Ethernet) y, a veces, más (WiFi, otra tarjeta de red, etc.). La interfaz de loopback está siempre presente y, si no queremos probarla, se puede omitir haciendo un simple test sobre el nombre (que siempre es "lo", pero en cualquier caso, el nombre puede verificarse con antelación, para evitar malentendidos, en el file /etc/network/interfaces).

El test de conectividad se basa, en vez, en una simple conexión de tipo Client a una dirección "segura": En el ejemplo he usado IP y Port de google.com, pero se puede usar la que parece más apropiada, por ejemplo, para un dispositivo conectado solo a la red local, se puede usar la conexión a un servidor en la red, o bien se puede conectar a la dirección del gateway local, etc. También depende de si lo que tenemos que probar es conectividad a Internet o una simple conectividad local. Tener en cuenta que todo funciona usando la system call connect(), que implementa el envío de datos y la recepción de una respuesta, por lo que es un test más que suficiente (sin recurrir a un mucho más complicado ping). Ya que connect() se bloquea durante mucho tiempo cuando no recibe una respuesta inmediata, he añadido un oportuno timeout (leer el comentario en el código) utilizando setcsockopt() + SO_SNDTIMEO, pero (leer el otro comentario) también se puede usar el flag TCP_SYNCNT, que es, pero, una solución menos ortodoxa y menos portátil.

En un normal PC (en lugar de un sistema embedded) con una conexión a Internet a través de Ethernet, el resultado en condiciones normales es el siguiente:
aldo@mylinux:~/blogtest$ ./conntest 
test interfaces: interface lo: OK
test interfaces: interface enp3s0: OK
test de conectividad: conectividad OK
y, si forzamos la desconexión del Software (utilizando, por ejemplo, el NetworkManager de Linux) el resultado es:
aldo@mylinux:~/blogtest$ ./conntest 
test interfaces: interface lo: OK
test interfaces: interface enp3s0: OK
test de conectividad: error connect: Network is unreachable
mientras que si forzamos la desconexión Hardware (desconectando el cable de red) el resultado es:
aldo@mylinux:~/blogtest$ ./conntest 
test interfaces: interface lo: OK
test interfaces: interface enp3s0: NOK
test de conectividad: error connect: Network is unreachable
No está mal, ¿verdad? Una función simple simple pero muy útil. ¡Y por hoy ya està, misión cumplida!

¡Hasta el próximo post!

domingo, 14 de enero de 2018

Remapped File
cómo sincronizar un Memory Mapped File en C - pt.2

Bueno, creo que es hora de publicar la segunda parte de Remapped File. Espero que hayáis recargado bien las pilas durante las vacaciones, tal vez viendo una gran película como Primer, que internamente contiene varios remakes de sí misma: podéis verla tantas veces como queráis y cada vez descubriréis nuevos detalles e, inevitablemente, os perderéis detalles antiguos, entrando en un loop temporal sin fin como los mismos protagonistas de la película. Os aseguro que el post de este mes no es tan complicado de entender como Primer, de la cual se encuentran en la web hasta páginas wiki dedicadas a las timeline con descripciones gráficas incluidas...
...¿qué apareció antes, el huevo o la gallina?...
Entonces, sigamos con nuestra biblioteca para IPC. Después de describir el header file (libmmap.h) y un doble ejemplo de uso (datareader.c y datawriter.c), es hora de describir la implementación real. Obviamente quien no ha leído la primera parte debe estar avergonzado e ir a leerla de inmediato, y luego volver aquí.

Tornati? Ok, vamos al grano, ¡vamos con el código!
#include <string.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
#include "libmmap.h"

// memMapOpenMast() - abre un mapped-file como master
ShmData *memMapOpenMast(
    const char *shmname,    // nombre del mapped file
    size_t     len)         // size del campo data a compartir
{
    // abre un mapped-file (el file "shmname" se crea en /dev/shm)
    int fd;
    if ((fd = shm_open(shmname, O_CREAT|O_RDWR, S_IRUSR|S_IWUSR)) == -1)
        return NULL;    // sale con error

    // corta un mapped file
    if (ftruncate(fd, sizeof(ShmData) + len) == -1)
        return NULL;    // sale con error

    // mapea un mapped-file
    ShmData *shmdata;
    if ((shmdata = mmap(NULL, sizeof(ShmData) + len,
            PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0)) == MAP_FAILED)
        return NULL;    // sale con error

    // init semaforo
    if (sem_init(&shmdata->sem, 1, 1) == -1)
        return NULL;    // sale con error

    // init flag de data_ready y longitud
    shmdata->data_ready = false;
    shmdata->len = len;

    // retorna el descriptor
    return shmdata;
}

// memMapOpenMast() - abre un mapped-file como slave
ShmData *memMapOpenSlav(
    const char *shmname,    // nombre del mapped-file
    size_t     len)         // size del campo data a compartir
{
    // abre un mapped-file (il file "shmname" se crea en /dev/shm)
    int fd;
    if ((fd = shm_open(shmname, O_RDWR, S_IRUSR|S_IWUSR)) == -1)
        return NULL;    // sale con error

    // mapea un mapped-file
    ShmData *shmdata;
    if ((shmdata = mmap(NULL, sizeof(ShmData) + len,
            PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0)) == MAP_FAILED)
        return NULL;    // sale con error

    // init semaforo
    if (sem_init(&shmdata->sem, 1, 1) == -1)
        return NULL;    // sale con error

    // retorna el descriptor
    return shmdata;
}

// memMapClose() - cierra un mapped-file
int memMapClose(
    const char *shmname,    // nombre del mapped-file
    ShmData    *shmdata)    // pointer al mapped-file
{
    // elimina semaforo
    if (sem_destroy(&shmdata->sem) < 0)
        return -1;      // sale con error

    // de-mapea un mapped-file
    if (munmap(shmdata, sizeof(ShmData)) < 0)
        return -1;      // sale con error

    // cancela un mapped-file
    if (shm_unlink(shmname) < 0)
        return -1;      // sale con error

    // esce con Ok
    return 0;
}

// memMapFlush() - flush de un mapped-file
int memMapFlush(
    ShmData *shmdata)       // pointer al mapped-file
{
    // sync en disco de un mapped-file
    return msync(shmdata, sizeof(ShmData) + shmdata->len, MS_SYNC);
}

// memMapRead() - lee datos del mapped-file
int memMapRead(
    void    *dest,
    ShmData *src)
{
    // lock memoria
    sem_wait(&src->sem);

    // test presenciaa datos en el mapped-file
    if (src->data_ready) {
        // lee datos del mapped-file
        memcpy(dest, src->data, src->len);
        src->data_ready = false;

        // unlock memoria y sale
        sem_post(&src->sem);
        return 1;
    }
    else {
        // unlock memoria y sale
        sem_post(&src->sem);
        return 0;
    }
}

// memMapWrite() - escribe datos en el mapped-file
void memMapWrite(
    ShmData    *dest,
    const void *src)
{
    // lock memoria
    sem_wait(&dest->sem);

    // escribe datos en el mapped-file
    memcpy(dest->data, src, dest->len);
    dest->data_ready = true;

    // unlock memoria y sale
    sem_post(&dest->sem);
}
Como se puede ver es bastante simple y conciso, y, como siempre, el código es auto-explicativo, ampliamente comentado y los comentarios hablan por sí mismos. 

Todas las funciones utilizan, internamente, las oportunas system call Linux/POSIX para procesar el nuestro Memory Mapped File. En caso de error en una system call  se devuelve inmediatamente -1, y esto nos permite, a nivel de aplicación, usar directamente strerror() para verificar el error (y este es un tema que mis lectores más leales deberían conocer bien...). Como podeis ver, hay dos funciones de open, una master y una slave: ¿porqué? Porqué, como el tipo de comunicación elegido es (ligeramente) asimétrico, es necesario que uno de los dos extremos (el writer) abra el canal, mientras que el otro (el reader) acceda al canal cuando lo encuentra creado. Entonces ahora se entiende mejor (espero) cómo funcionan las dos funciones descritas en la primera parte del post. Este mecanismo asimétrico recuerda mucho al mecanismo Client/Server que se usa con los socket (otro tema ya discutido aquí) y, de hecho, esta librería es una alternativa al IPC clásico con los socket.

Las funciones de read y write se limitan en usar memcpy() para copiar los datos desde/hacia el mapped-file. Y, como se anticipó en el post anterior, las lecturas y escrituras utilizan un mecanismo de sincronización (un POSIX unnamed semaphore) que se inicializa en las funciones de open: simplemente quién accede a los datos pone en rojo (lock) el semáforo (entonces quién llega despues se detiene) y cuando termina, lo vuelve a poner en verde (unlock).

La función de flush es sólo un wrapper para la llamada msync() y, normalmente, no es necesario utilizarla: con esta librería queremos tratar a los archivos mapeados en memoria para compartir datos entre procesos, por lo que, no sólo nos interesa poco que el archivo tenga una imagen real en el disco, sino que, por una simple cuestión de rendimiento, deberíamos evitar de descargar en el disco todos los cambios realizados en la memoria, si no seria como usar files reales. Entonces, ¿de que sirve el flush? Sirve sólo para mantener una eventual versión real y actualizada del file compartido, en el caso que queremos tratarlo, también, con la clásicas funciones open(), close(), read(), etc. Por esto en el file msgwriter.c descritos en el post anterior la llamada memMapFlush() no está utilizada.

Y llegamos a la otra novedad presentada en esta nueva versión de libmmap: los datos procesados ahora son genéricos, por lo que las funciones de read y write usan void* como argumentos: esto es una gran ventaja, ya que permite intercambiar datos en IPC usando cualquier formato; una estructura compleja o una sola variable (¿yo que se?, ¿un int?). Por ejemplo, en el último post he definido un tipo Data (una struct con un campo text) para usarla en el nivel aplicación y que se puede pasar como un argumento para las read y write sin siquiera hacer un cast. Una gran flexibilidad, similar a la de las funciones de la libc como la memcpy(), pero con algo más: el tamaño (e, indirectamente, el tipo) de los datos intercambiados se pasa, de una vez por todas, durante la fase de open (a través del parámetro len), por lo que las funciones de read y write no tienen el clásico campo "size_t len" que cualquiera se esperaría.

Solo tenemos que describir una cosa: el truco del "char data[1]" utilizado para hacer que los datos compartidos sean genéricos. Este campo es (como era de esperar) el último de la estructura de datos que describe el mapped-file, y funciona así: cuando creas el file se pasa, a la memMapOpenMast(), el size de los datos a intercambiar (con un operador sizeof, ver el ejemplo de el último post), y, como podemos ver en el código de la memMapOpenMast(), el mapped-file se mapea utilizando la system call mmap() pasandole un argumento length que indica el tamaño del mapped-file en cuestión: en nuestro caso pasamos "sizeof(ShmData) + len", por lo que el mapped-file está configurado para intercambiar datos en su parte variable "char data[1]", que, de base, es larga un char, pero es, en realidad, larga len char una vez que el file ha sido mapeado. Un truquito de nada.

Espero que os haya gustado la nueva versión de la librería. Os aseguro que, con solo algunas mejoras (como la gestión de todos los errores internos posibles, añadir otro semáforo para administrar el lock en read/write, agregar mecanismos de acceso blocking/nonblocking... ¡bien, tal vez es un poco más que algunas mejoras!), se podría usar en proyectos profesionales... ¿y os parece poco?

¡Hasta el próximo post!