Journal Ecrasez un Mammouth !

Posté par JaguarWan le 01 juillet 2005 à 03:08.

Étiquettes : aucune

juil.

2005

Bonjour (ou plutôt bonsoir pour les noctambules),

J'ai fini une version plutôt stable de mon serveur multiservices/multiprotocoles, et j'ai jugé le moment opportun pour vous remercier, tous les linuxfriens qui m'ont patiemment aidé sur les forums C, et vous montrer ce que j'ai codé avec mes doigts boudinés grâce à vos conseils avisés :)

Le serveur fait actuellement tourner un plugin HTTP presque compatible 1.0 (il manque encore POST et l'authentification basique), et marche sous GNU/Linux (évidemment), Mac OS X et Windows 2k/XP.

Je vous serais reconnaissant si vous pouviez malmener le Mammouth qui tourne sur http://michoko.homeip.net:8080/(...) (64 ko/s en upload), comme ça s'il plante sous la charge j'aurais un beau core dump à analyser :]

Vous pourrez aussi y télécharger les sources (sous licence GPL) si ça vous intéresse :)

Voilà, merci beaucoup à tous ceux qui prennent le temps d'aider les apprentis codeurs sur les forums :D

P.S: Il s'appelle Mammouth car il a toujours eu des tendances d'usine à gaz :]

# Date limite

Posté par JaguarWan le 01 juillet 2005 à 03:12. Évalué à 4.

Attention, le serveur ne pourra plus être écrasé à partir de demain ce vendredi soir, car mon sympathique hébergeur déménage sa bête ce week end :)
- [^] # Re: Date limite
  
  Posté par Olivier Grisel (site web personnel) le 01 juillet 2005 à 03:51. Évalué à 6.
  
  mamouth écrasé ?
  
  """
  bzip2: Data integrity error when decompressing.
  Input file = (stdin), output file = (stdout)
  
  It is possible that the compressed file(s) have become corrupted.
  You can use the -tvv option to test integrity of such files.
  
  You can use the `bzip2recover' program to attempt to recover
  data from undamaged sections of corrupted files.
  
  /bin/gtar: Child returned status 2
  /bin/gtar: Statut d'erreur reporté d'erreurs précédentes.
  """
  - [^] # Bien vu...
    
    Posté par JaguarWan le 01 juillet 2005 à 04:59. Évalué à 2.
    
    Premier bug révélé par l'affluence (j'ai été surpris quand j'ai vu la taille du access.log !), les transferts de "gros" fichiers ne sont plus fiables.
    
    En effet, je compile habituellement Mammouth avec seulement deux threads travailleurs de chaque sorte (MM_LIMIT_THREAD dans net/mm_net_def.h), mais là j'en avais prévu idix (juste au cas où ^_^').
    
    Malheureusement, je n'avais pas prévu de mécanismes garantissant un envoi séquentiel pour les nouveaux streams, vu qu'empiriquement ça semblait bien marcher... Ce qui fait que vous recevez le fichier en entier, mais tout mélangé suivant la vélocité relative des 10 travailleurs d'écriture :]
    
    Bon, bah ça fait un nouvel item sur ma todo list, en prévision d'une très prochaine version 0.2.1 :D
    
    En attendant, il est conseillé de récupérer les sources sur tuxfamily ^_^'
- [^] # Re: Date limite
  
  Posté par Khâpin (site web personnel) le 01 juillet 2005 à 06:03. Évalué à 7.
  
  Un truc bizarre: quand je fais un wget http://michoko.homeip.net:8080/(...)
  il reste bloqué à 0%, mais après un Ctrl+C, le fichier téléchargé est correcte.
  Même chose avec wget http://michoko.homeip.net:8080/mammoth.gif(...)
  il se bloque à divers pourcentages, mais l'image est correcte (et les images sont identiques, quelque soit le pourcentage auquel le téléchargement s'est arrêté)
  
  Du coup, ton site n'est pas visible avec lynx.
  
  Autre chose bizarre, http://michoko.homeip.net:8080/a.html(...) me donne bien ta (très jolie) page 404, mais avec un code 200!
  - [^] # Re: Date limite
    
    Posté par mrlem (site web personnel) le 01 juillet 2005 à 08:54. Évalué à 3.
    
    > il reste bloqué à 0%, mais après un Ctrl+C, le fichier téléchargé est correcte.
    
    Peut-être un problème dans l'entête HTTP annonçant la content-length qui permet à wget de dire où il en est ?
    
    > il se bloque à divers pourcentages, mais l'image est correcte (et les images sont identiques, quelque soit le pourcentage auquel le téléchargement s'est arrêté)
    
    Si la content-length n'est pas envoyée, et que le serveur ne prend pas l'initiative de fermer la connexion, le client doit être bien embêté :-P En même temps je fabule peut-être, vu que je ne peux accéder au site pour vérifier cette hypothèse...
  - [^] # Re: Date limite
    
    Posté par JaguarWan le 01 juillet 2005 à 11:27. Évalué à 1.
    
    Heu, le coup de la 404 ça doit être un problème de conformance HTTP: quand je détecte un forbidden/not found, j'envoie directement la page 404 comme un document normal :)
    Je mettrais un CGI pour contrôler ça dans la prochaine version :)
    
    Pour wget, mon serveur ne ferme pas la connection tant que le client est là... Avec un telnet on voit qu'il envoie Content-Length et Content-Type, mais il doit manquer quelque chose pour que wget soit content car même dans des conditions "normales" il reste bloqué à 100%...
    
    Vu que le serveur ne répondait plus beaucoup, je lui ai balancé un kill -11 pour voir s'il était en deadlock :)
    
    Après lecture du core dump, il apparaît qu'il était tout simplement en stress intense, c'est impressionnant un LinuxFRisage :)
# Moi de même

Posté par Ummon le 01 juillet 2005 à 08:48. Évalué à 3.

Hello très cher collègue, j'ai également réalisé mon propre serveur web qui est également presque compatible HTTP 1.0/1.1 :o)
Il n'est pas encore possible de le télécharger car ce n'est pour l'instant qu'une version alpha.

Vous pouvez essayé de le malmener ici :
http://pifou.myftp.org:8080/(...)
- [^] # Re: Moi de même
  
  Posté par JaguarWan le 01 juillet 2005 à 16:55. Évalué à 2.
  
  Le tiens a l'air plus fiable, il est resté disponible tout du long :) En plus apparemment tu peux utiliser du php avec, c'est déjà bien avancé pour une alpha :)
  
  Par contre j'ai voulu faire un telnet dessus et il ne répond pas quand je lance un bête GET / HTTP/1.1...
# Outils

Posté par dguihal le 01 juillet 2005 à 10:28. Évalué à 2.

Et pourquoi ne pas utiliser un outil de test de charge pour malmener ton serveur? Voire meme developper un simple script Shell/Perl, ca ne devrais pas etre trop compliqué
- [^] # Re: Outils
  
  Posté par Yth (Mastodon) le 01 juillet 2005 à 10:43. Évalué à 5.
  
  Il le linuxfrise, c'est pas mal je pense comme stress-test ;)
  
  Yth.
- [^] # Re: Outils
  
  Posté par JaguarWan le 01 juillet 2005 à 11:32. Évalué à 4.
  
  Bah, je voulais voir un exemple de La Vie Réelle® et aussi pouvoir remercier les LinuxFRiens qui m'ont aidé :) Donc hop, une pierre deux coups :)
- [^] # Re: Outils
  
  Posté par Loïs Taulelle ࿋ (site web personnel) le 01 juillet 2005 à 21:04. Évalué à 1.
  
  outil de test de charge
  
  Comme siege ?
  Proverbe Alien : Sauvez la terre ? Mangez des humains !
# Même chose en Java :-)

Posté par Olivier Serve (site web personnel) le 01 juillet 2005 à 10:37. Évalué à 2.

C'est marrant, j'ai un projet similaire en Java. C'est un serveur TCP qui peut faire tourner simultanément plusieurs protocoles (sur différents ports bien sûr), avec des extensions (statiques) et des services (sortes d'extensions dynamiques).

Pour le moment, je n'ai pas de 'virtualhost' HTTP, mais c'est prévu.

https://tifauv.homeip.net/svn/neutron/(...)
# Arf

Posté par JaguarWan le 01 juillet 2005 à 12:09. Évalué à 1.

J'ai été maladroit, j'ai tué le serveur pour voir s'il était en deadlock mais je ne peux plus le relancer à cause d'une erreur de bind...

A la lumière de netstat, on peut voit que le socket d'écoute est coincé en FIN_WAIT1...

pingouin@MICHOKO:~/MammouthServer-0.2/Mammouth$ netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 MICHOKO.ma:microsoft-ds 192.168.0.4:32770 ESTABLISHED
tcp 0 16362 126.20.97-84.rev.g:8080 dhcp-83-219-107-17:3920 FIN_WAIT1
tcp 0 48 126.20.97-84.rev.ga:ssh AAmiens-152-1-38-:57363 ESTABLISHED

En attendant (cependant je ne crois pas que FIN_WAIT1 ait un timeout), je pense qu'on peut déclarer le Mammouth écrasé...

Les sources sont disponibles sur http://mammouth.tuxfamily.org(...)
- [^] # Re: Arf
  
  Posté par galactikboulay le 05 juillet 2005 à 10:14. Évalué à 1.
  
  Si tu veux passer outre, tu peux utiliser setsockopt() avec l'option SO_REUSEADDR (après avoir créé ton socket).
  
  Même s'il te reste des connexions en attente de fermeture (en FIN_WAIT), tu pourras "rebinder" le port.
# PLouf ?

Posté par Vanzetti le 01 juillet 2005 à 13:47. Évalué à 2.

Bein il repond plus le mamouth !
on est pas encore vendredi soir !!!
je veux voir ! je veux voir !!!
- [^] # Re: PLouf ?
  
  Posté par JaguarWan le 01 juillet 2005 à 16:41. Évalué à 2.
  
  Héhé, le TCP_FIN est parti, le Mammouth est relancé :)
  J'espère que cette erreur bizarre ne se reproduira pas...
  - [^] # Re: PLouf ?
    
    Posté par Michel Pastor le 01 juillet 2005 à 19:42. Évalué à 3.
    
    A mon avis ton erreur est due au fait que le socket n'est pas supprimmé tout de suite mais par défaut environ 1 minute après la terminaison de ton serveur.
    
    Pour corriger ce problème il faut positionner l'option SO_REUSEADDR sur le socket pour lui indiquer que ce n'est pas fatal. Un appel a setsockopt() juste après ta création du socket avec socket() devrait faire l'affaire:
    
    int optval = 1;
    int socket;
    socket = socket(...);
    if (setsockopt(socket, SO_REUSEADDR, &optval, sizeof(optval)) == -1)
    // erreur
    ...
    
    man setsockopt pour le reste ;)

Suivre le flux des commentaires

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