Mi Proyecto para el GSoC
“Lo maravilloso del mundo de la informática, es que sólo otro informático puede valorar realmente tu trabajo”. Con esta frase quiero reflejar lo irónico que normalmente resulta explicar nuestros trabajos a alguien no informático.
Que hayas escrito 1500 líneas de código no supone nada, pero menos aún cuando ese código se encarga de algo que uno podría hacer casi sin pensar, pero no saben que tras esa fachada de código sin sentido puede esconderse un intrincado algoritmo.
En esta “entrada / artículo” intentaré explicar de la forma más fácil posible en que consiste el proyecto que he propuesto para el GSoC, y en el cual trabajaré sea aceptado o no 
. Puesto que el proyecto se titula “Librería de Sockets multiplataforma en C++”, explicaré primero el título.
Para empezar ¿Qué es C++?. C++ es un lenguaje de programación orientado a objetos, pero sólo con entender que es un lenguaje de programación basta. Es el lenguaje en el cual realizaré el proyecto, así que todo el código estará escrito en C++.
Con “multiplataforma”, me refiero a que debe funcionar tanto en Linux (Ubuntu, Debian, Fedora, Suse, etc, etc.), como en MAC OS X, Solaris o incluso Windows.
Además, es una librería, que en informática se entiende como una colección de funciones que los programadores usamos en nuestros programas; y entre otras cosas, nos hacen la vida un poco más fácil porque nos abstraen de hacer cosas que ya están resueltas y nos permite centrarnos en el problema a resolver. Por tanto, al ser una librería, contendrá funciones que en un futuro otros programadores podrán usar en sus programas para no complicarse y perder el tiempo volviéndolo a hacer.
Lo único que queda por explicar es la palabra “socket”, que he dejado sin traducir. Un socket sirve para establecer una comunicación con otro PC. Para aclarar y siendo un poco injusto con lo que realmente es un socket, podemos entender el concepto de socket, ni más ni menos, como algo que puede envíar y recibir información que viaja a través de Internet. Obviamente en el otro extremo de la comunicación debe haber otro socket.
Como ejemplo, cuando abres tu navegador web (firefox de ahora en adelante) y entras a una página web, este crea un socket para conectarse con tu servidor web, que a su vez tiene un socket esperando la llegada de nuevas conexiones que atender. Mi proyecto consiste en hacer más fácil la forma en que un programador usa estos sockets, pues si bien, no todo empieza y acaba con un socket.
Podríamos establecer una anología entre los elementos que intervienen en una comunicación y el ejemplo anterior:
- emisor = firefox
- receptor = servidor web (Vgr. el que aloja a meneame.net )
- canal = Internet
- Protocolo = HTTP
- Mensaje = “Quiero que me muestres la página X”
El protocolo o conjunto de reglas que se emplea en la comunicación es el lenguaje que ambos participantes de la comunicación entienden, igual que ahora mismo para entender este texto hay que conocer las reglas del castellano.
En Internet se emplea el protocolo IP y de ahí que todo el mundo conectado a Internet tenga un número conocido como dirección IP. El protocolo IP sirve para que los datos sepan que camino han de tomar para llegar a su destino. Por otro lado tenemos el protocolo TCP, que se encarga de que los datos no se pierdan por el camino, garantizando que los datos enviados por el emisor lleguen correctamente al receptor. Digamos que TCP se inventó para ayudar a IP, ya que en IP los datos pueden llegar desordenados o perderse por el camino sin que el otro extremo se de cuenta.
¿Que relación tiene todo esto con los sockets? Pues porque el único protocolo que entiende un socket es TCP/IP (en verdad entiende más). Un socket no tiene ninguna idea de como “conectarse al MSN”, “obtener una página web”, “envíar un archivo”, “recibir un email”, etc. Por tanto, cada aplicación que quiera hacer una de estas cosas tiene que conocer las reglas (protocolos) para realizar estas acciones. Gracias a TCP/IP tenemos lo necesario para poder construir sobre esta sólida base nuevos protocolos, que llamaremos protocolos de Nivel Aplicación.
Volviendo al proyecto, la idea sería construir protocolos de nivel aplicación con estos sockets que hemos dicho solo entienden TCP/IP. ¿Y para qué todo esto? Lo explico a continuación.
Existe una vasta diversidad en cuanto a protocolos de nivel aplicación pero el más conocido por el usuario probablemente sea el HTTP, empleado cada vez que vemos una página web, y también por eso escribimos “http://” delante de las direcciones de las webs, de esta forma le indicamos al Firefox que protocolo emplear para comunicarse con el servidor.
Además de Firefox, existen más navegadores, como por ejemplo: Opera, Safari, Konqueror, Ephiphany, Internet Explorer y muchos más. Cada una de estas aplicaciones debe entender el protocolo HTTP y para ello deben programarlo o implementarlo usando sockets TCP/IP. El problema de esto es que cada uno tendrá una implementación de HTTP, lo que se traduce en una duplicación de esfuerzos. Además, si en un futuro el estándar HTTP cambia, cada una de esas implementaciones deberá adaptarse al estándar. Esto no solamente pasa con HTTP, como ya dije antes, existe una vasta diversidad de protocolos (FTP, SMTP, POP3, SSH, IRC, MSNP, IMAP, JABBER …) y por tanto, si cada uno tiene su propia implementación del estándar se intensifica el problema.
La librería de sockets ofrece una solución a este problema haciendo exactamente lo mismo, duplicar esfuerzos, me explico. La solución es reunir todos estos protocolos en un único lugar para que así, cada aplicación que necesite comunicarse con cualquier otra aplicación pueda recurrir a estos protocolos y utilizarlos. Al estar todo centralizado y compartir cada aplicación la misma implementación de un protocolo, si el estándar cambia, únicamente habría que adaptar una implementación y el resto de aplicaciones que la usen se beneficiarían inmediatamente.
La idea es sencilla, pero muy costosa de realizar pues sería volver a escribir lo que ya existe y además hacerlo de una forma intuitiva para que sea fácil de utilizar. Además, debe poder ampliarse con facilidad para agregar nuevos protocolos y resistir el paso del tiempo.
Durante el Summer of Code sería imposible realizarlo todo una sola persona, por lo que únicamente me centraría en hacer todo lo que la librería debería ofrecer a un programador para facilitarle la tarea de implementar cualquier protocolo. Una vez conseguido esto y a modo de ejemplo, trabajaría en una implementación incompleta del protocolo HTTP, que sería completada si quedase tiempo o posteriormente fuera del Summer of Code.
Como puede verse no es algo innovador ni genial, si trabajoso, pero por supuesto se aceptan sugerencias e ideas que puedan ayudar al desarrollo del proyecto ).