Journal Gophrier 0.1

Posté par  (site web personnel) .
Étiquettes :
13
28
jan.
2011
Heya 'nal,

Suite à l'échec cuisant de mon précédent journal, j'ai décidé de vous parler d'un autre de mes super projets, codé à la sueur de mes petits doigts musclés.

Donc voila, ça s'appelle Gophrier, c'est disponible ici : http://gophrier.tuxfamily.org (avec un site magnifique que j'ai mis des heures à mettre en page), c'est un serveur gopher et c'est une première version (si vous n'avez pas le courage, le lien pour télécharger, c'est http://download.tuxfamily.org/gophrier/gophrier-0.1.0.tar.gz ). Bien sur, cette première release est loin d'être complète et je ne vous conseille pas de l'utiliser tout de suite en production pour remplacer vos actuels clusters de serveurs gopher. Le but est plus de présenter ce nouveau projet à vous tous, apprentis auto-hébergeurs et autres nostalgiques de technologies dépassées.

En plus du site, le code est lui aussi hébergé chez TuxFamily, dans un dépôt Mercurial (car oui, rappelons le, TuxFamily fait aussi du Mercurial), visible ici : http://hg.tuxfamily.org/mercurialroot/gophrier/gophrier/

Donc voila, je crois que j'ai tout dit ; si vous avez le courage de tester, je suis preneur de vos retours.

  • # Pour les ignorants comme moi

    Posté par  . Évalué à 10.

    Un petit lien pour savoir ce qu'est le protocole GOPHER :
    https://secure.wikimedia.org/wikipedia/fr/wiki/Gopher

  • # Pourquoi

    Posté par  . Évalué à 6.

    Etant donné que le protocole gopher est mort dans les années 90 supplanté par http, je suis sincèrement curieux de savoir ce qui a pu te motiver à écrire ce serveur.
    Y a t'il des avantages que je ne vois pas à cette technologie par rapport à ce qui se fait maintenant ?

    • [^] # Re: Pourquoi

      Posté par  . Évalué à 6.

      C'est bien connu des vieux briscards, c'est plein de nostalgie et puis d'abord il avait envie, voilà tout!

      Par contre ça va pas être facile côté client:
      IE6 ne supporte pas (ni les suivants), Firefox ne supportera plus à partir de la version 4 (imminente tout de même), et je ne parle pas des autres...

      • [^] # Re: Pourquoi

        Posté par  . Évalué à 8.

        mais si, c'est une superbe opportunité, comme ça il va pouvoir également coder un client gopher ou un plugin firefox ou un hack IE(6-8) pour se connecter à Gophrier.

        Et si c'est un client kde, il pourra l'appeler suKreglace. D'ailleurs si c'est un client gnome il pourra l'appeler également sukreGlace, voire gtk-sucreglace.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Pourquoi

          Posté par  (site web personnel) . Évalué à 5.

          En fait, il y a déjà le projet Overbite : http://gopher.floodgap.com/overbite/ qui fournit le support gopher à différents navigateurs.

          Quand à KDE, il y a kio_gopher qui permet d'avoir la fonctionnalité dans Konqueror (et dans le reste de KDE, vu que c'est un KIO)

        • [^] # Re: Pourquoi

          Posté par  . Évalué à 1.

          Firefox n'a pas besoin d'extension, le protocole est déjà géré.

          • [^] # Re: Pourquoi

            Posté par  . Évalué à 3.

            Il sera retiré à partir de Firefox 4.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Pourquoi

        Posté par  (site web personnel) . Évalué à 6.

        Ils ont donc entamé la migration navigateur internet -> navigateur web. Bientôt la suppression du FTP.
        Bon vendredi à tous. ~~~~> [ ]

        • [^] # Re: Pourquoi

          Posté par  . Évalué à 1.

          En fait, ce qui manque à Gopher, c'est un joli logo...

    • [^] # Re: Pourquoi

      Posté par  . Évalué à 3.

      À mon avis c'est plus motivant d'écrire un serveur Gopher qu'un serveur HTTP qui devra lutter contre tous ceux qui existent déjà.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Pourquoi

      Posté par  (site web personnel) . Évalué à 4.

      Cela fait suite à plusieurs discussions avec des admins de TuxFamily (tf.o) ou l'on se demandait s'il serait possible d'ajouter le protocole gopher à l'offre actuelle de tf.o

      Bien sur, je ne pense pas qu'un jour tf.o propose réellement du gopher à ses hébergés, mais j'ai trouvé l'idée amusante et comme je n'avais jamais codé de "vrai" truc réseau, je m'y suis mis... voila :)

    • [^] # Re: Pourquoi

      Posté par  . Évalué à 4.

      je suis sincèrement curieux de savoir ce qui a pu te motiver à écrire ce serveur.

      Trop de temps libre ? http://xkcd.com/554/

  • # Vas-tu rajouter le support pour...

    Posté par  (site web personnel) . Évalué à 10.

    IPX? Parce que si je ne peux pas l'utiliser sur mon réseau token ring, ce sera une barrière pour moi.

  • # J'aime pas

    Posté par  (site web personnel) . Évalué à 4.

    Les fichiers sources qui commencent par 20 ligne de licence et pas une seule pour expliquer un minimum ce qu'il contiens. :(

    • [^] # Re: J'aime pas

      Posté par  (site web personnel) . Évalué à 5.

      Oui, pour une application aussi critique j'ai souhaité placer le niveau de sécurité du code au maximum et donc ne rien commenter. Dommage que j'ai été obligé d'ajouter les 20 lignes de licence...

      Plus sérieusement, mon code n'est en effet pas commenté, désolé. J'essaierais d'améliorer ça dans un futur proche.

    • [^] # Re: J'aime pas

      Posté par  . Évalué à 3.

      Bah si, ligne 3 de chaque fichier, tu as :

      « This file is part of Gophrier. »

  • # Suggestions

    Posté par  . Évalué à 7.

    Petites suggestions techniques :

    - utiliser epoll au lieu de select
    - utiliser des socket non bloquantes
    - mieux : utiliser des sockets asynchrones pour éviter qu'un client ne bloque les autres
    - lire de manière asynchrone les fichiers sur le disque dur pour ne pas bloquer le processus sur un fichier
    - annuler les requêtes d'un client s'il se déconnecte en cours de route pour ne pas bouffer de ressources pour rien.

    Je te conseille vivement d'utiliser Boost::Asio (c++) pour faire ton serveur ou bien libgio si tu tiens a rester en C... ces librairies te permettent de programmer de manière asynchrone très facilement.

    • [^] # Re: Suggestions

      Posté par  (site web personnel) . Évalué à 4.

      Comme précisé un peu plus haut, je n'ai pas forcément de grosses compétences en dev réseau, j'aurais donc quelques questions sur tes suggestions :)

      - quel est l'avantage de epoll sur select ? j'avoue ne pas du tout connaitre epoll. "man epoll" m'a juste dit que c'était spécifique linux et que ça avait l'air "moderne".

      - au moment du recv, j'ajoute le flag MSG_DONTWAIT pour que justement la lecture ne soit pas bloquante, après il y a surement un moyen de le faire au niveau de la socket directement...

      - heu... tu veux dire avec des fork et/ou threads ? sinon je ne vois pas ce que tu entends par "sockets asynchrones"

      - pareil qu'à la suggestion précédente, lecture de fichiers asynchrone => fork/thread ? en tout cas, tu as totalement raison, si un client se met à lire un gros fichier, les autres vont pleurer à côté

      - pour la dernière suggestion, oui, ça serait en effet mieux que je ne laisse pas le serveur travailler pour rien

      Et sinon, oui, j'aimerais bien rester en pur C et sans trop de dépendances, ça donne un côté super viril au truc.

      • [^] # Re: Suggestions

        Posté par  . Évalué à 1.

        "lecture de fichiers asynchrone => fork/thread ?"
        C'est tout l'inverse, les opérations d'E/S asynchrone visent à ne pas utiliser de fork/thread.

        Les forks/threads sont nécessaires quand un appel de fonction risque de durer longtemps et donc d'empêcher de faire d'autres choses. Mais les E/S peuvent être utilisées de façon à ce qu'elles ne bloquent pas le reste.
        Une opération d'E/S dite "synchrone" peut être lente, car l'appel à fread/fwrite (par exemple) ne se terminera qu'une fois les octets lus/écrits.
        Je n'ai pas lu votre code, mais de ce que j'ai compris, vous avez utilisé select pour "lire" tous les sockets dans un seul endroit, plutôt que d'utiliser un thread par client (où chaque thread ferait de bêtes lectures bloquantes, même s'il ne se passe rien les 3/4 du temps).
        select et consorts sont une idée de début pour faire des E/S "asynchrones" comparé à "un thread par client".

        • [^] # Re: Suggestions

          Posté par  . Évalué à 1.

          Faire un thread par client, à la vue actuelle du coût d'un thread (en mémoire et temps CPU pour le changement de contexte) est une très mauvaise idée.
          Actuellement la meilleure stratégie consiste à utiliser le pattern Reactor (avec epoll ou select), associé à pool de thread (2 thread par processeurs est un bon consensus) pour gérer les travaux à effectuer (lecture/ecriture entrée/sortie asynchrones, calculs complexes, lancement de scripts [php/python/java/rails etc] etc ).

      • [^] # Re: Suggestions

        Posté par  . Évalué à 1.

        - quel est l'avantage de epoll sur select ?
        L'avantage se situe sur l'algorithme de parcours et le nombre de connections simultanées que tu peux gérer. En effet, actuellement, tu es obligé après le select de parcourir tous les descripteurs pour savoir s'il y a quelque chose a lire. Avec epoll tu ne parcours que les descripteurs ou il y a quelque chose a lire. Dans un contexte avec de multiples connections, c'est indéniablement plus rapide.

        j'ajoute le flag MSG_DONTWAIT
        Tu peux utiliser fcntl(fd, F_SETFL, O_NONBLOCK) pour faire en sorte que la socket ne soit pas bloquante.

        Socket: tu veux dire avec des fork et/ou threads ?
        Non, celà signifie d'utiliser une boucle et d'employer des callbacks quand ce que tu as demandé a lire est disponible.
        C'est le même principe pour les fichiers. on peut utiliser epoll aussi bien pour des sockets que pour des fichiers. Tu utilises O_NONBLOCK aussi sur tes fichiers et quand tu fait un read(fd,buf,count) tu dois gérer EAGAIN comme un cas particulier a la lecture asynchrone.

        • [^] # Re: Suggestions

          Posté par  (site web personnel) . Évalué à 2.

          À noter qu'il existe des bibliothèques (libev/libevent de mémoire) qui permettent d'utiliser la meilleure méthode pour chaque système (epoll sur Linux par exemple, mais les autres systèmes ont leur équivalent), ce qui permet d'obtenir un code plus portable.

  • # J'ai un site Gopher

    Posté par  (site web personnel) . Évalué à 4.

    Bonjour aux fanas de Gopher !

    J'ai un site perso Gopher depuis septembre 2009 à:
    gopher://oceamer.com/

    Je viens aussi de sortir une application pour ce protocole. C'est un convertisseur de billets de blog pour en faire un gopher log (phlog). Les billets sont générés par le moteur de blog NanoBlogger. Il est existe une (petite) communauté d'utilisateur de NB (Nanoblogger).

    Le site officiel de NanoBlogger est à sourceforge :
    http://sourceforge.net/projects/nanoblogger/

    Le site officiel de ce convertisseur, nommé Nb2Gopher, est à :
    http://sourceforge.net/projects/nb2gopher/

    A titre d'exemple, on peut comparer les deux versions du même site, NanoBlogger francophone, un sur le Web, l'autre en Gopher:
    http://www.oceamer.com/~nanoblogger/
    gopher://oceamer.com/1/nanoblogger/

    Ceux qui cherchent des liens Gopher doivent aller sur gopherproxy.org et cliquer sur l'onglet statistics :
    http://gopherproxy.org/

    Vous y verrez que le nombre de gens sévèrement atteints de gophérite aiguë est peu élevé au niveau mondial. Quant au nombre de sites Gopher en France, ça doit se compter les doigts d'une seule main. Il y a un peu plus de renseignements dans Wikipedia en version "en" qu'avec la version "fr" pour Gopher.

    En tous cas, félicitations pour l'initiative du serveur !

  • # Implémentation de Gophrier sur mon site

    Posté par  (site web personnel) . Évalué à 8.

    J'ai réussi à compiler Gophrier et à l'installer sur ma machine, sur le port 7072. Par rapport aux maigres instructions, penser à faire en plus un "make install". J'avais re-paramétré le fichier "CMakeLists.txt" afin de définir les répertoires qui conviennent à mon système. Entre autres, celui de /var/gopher est déjà pris par mon serveur GoFish... Bon tout s'est bien passé quand même. Heureusement, car je ne connais pas un traître mot de langage C. Donc, on peut en conclure qu'avec un tutoriel bien détaillé, l'installation est jouable par toute personne méthodique. J'ai fait le paramétrage dans /etc/gophrier en y mettant les fichiers idoines. Là aussi, il faudra documenter. J'ai fait 2 réinitialisations consécutives de ma machine pour voir si le démon démarrait bien. Tout est OK. Le fichier de log fonctionne bien et il est bien utile. J'ai été obligé de tâtonner pour savoir quel était le nom du fichier gophermap. C'était tout bonnement "gophermap". Ce n'est pas évident car le serveur GoFish, par exemple impose ".cache", pour d'autres serveurs c'est ".gophermap". Donc à mettre d'urgence dans la doc, car il n'y a rien de normalisé dans ce domaine. Maintenant, ce que j'ai moins aimé:
    1. il faut impérativement mettre une barre oblique en début de sélecteur d'un fichier à la racine. Les autres serveurs sont plus tolérants. Mais, bon ça se discute.
    2. s'il n'y a pas de fichier gophermap, le contenu du répertoire s'affiche quand même. Certains serveurs sont permissifs à ce sujet, d'autres n'acceptent de ne servir que les fichiers qui sont inscrits dans le gophermap. C'est un choix du développeur, et seulement le sien.

    J'ai quand même trouvé un bug ! Selon la version première du Gopher, il y a un signe de fin de transmission qui est un "point" ajouté au fichier transmis. Si l'on prend la version Gopher+, il y a d'autres possibilités. A ce que j'ai compris, ce serveur n'est pas compatible Gopher+ et donc il devrait y avoir un "point" final. C'est bien ce qu'il fait quand il transmet le fichier gophermap mais pas avec un quelconque fichier texte. On peut analyser la transaction avec Netcat en faisant :

    echo -e /unfichier.txt'\r''\n'|nc example.com 70

    Bon, s'il n'y a que ça comme bug, ça peut s'arranger !
    Il y a un truc bizarre dans le sens où nmap ne détecte pas mon serveur. J'ai pourtant un serveur Pygopherd sur le port 7070 qui est bien vu par nmap (version 5.21)

    Pour voir, j'ai fait fonctionner mon convertisseur de blog vers phlog (nb2gopher) et tout s'est bien passé. Il faut dire que j'avais conçu nb2gopher avec plusieurs fichiers index identiques mais nommés différemment afin qu'un au moins soit compatible avec les serveurs en service. Comme j'avais prévu le cas de "gophermap", ouf! ça l'a fait.

    En conclusion, pour une version 0.1, c'est sévèrement noté. On pourrait l'établir à la version 0.3. Il reste à faire du cosmétique, comme mettre l'e-mail à côté du nom de l'auteur, à documenter, documenter et encore documenter. Il faudra aussi que l'auteur se détermine sur la politique de sécu et sur le niveau de permissivité. Si l'ambition se limite à ne faire qu'un serveur qui ne soit que minimal (c'est-à-dire pas compatible Gopher+), il semble que la version 1.0 ne soit pas si loin. Évidement, il faudra tester sur plusieurs machines et tous les clients en usage. Cette phase de test n'est pas évidente, vu le tout petit nombre de gophéristes. C'est pourquoi la mise des sources sur une forge connue comme Sourceforge.net, peut apporter de la visibilité au niveau international. Il faudra aussi savoir si l'ambition va vers le mono ou le multitread, autrement dit : la possibilité de servir plusieurs clients en même temps ou chacun son tour. C'est un point important quand un site propose en téléchargement des fichiers volumineux. Et également si une machine est faible et ne peut se permettre trop de clients connectés ensemble. Là encore, c'est le choix de l'auteur.

    Bon voilà. Vous pouvez aller sur mon site en employant les navigateurs suivant:

    Avec le vénérable et authentique client "gopher" :
    gopher -p/ oceamer.com 7072

    Avec Lynx :
    lynx gopher://oceamer.com:7072/

    Avec Firefox (+ module overbiteFF, indispensable avec un port différent de 70))
    gopher://oceamer.com:7072/

    -- Deber

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.