Partie I
Fonctionnement du client

Q.      Est-ce que plgrenouille fonctionne sous... <système autre que
        Linux> ?

R.      Non.

	Bien qu'écrit en Perl (donc portable), le programme accède
	directement au syscall gettimeofday() pour pouvoir utiliser un
	horloge de précision. Cet appel est présent sous la plupart
	des version UNIX (il fait partie de la norme POSIX), mais son
	numéro varie d'un système à l'autre.

	De plus, le programme utilise l'interface /proc/net/dev,
	spécifique à Linux, pour mesurer le débit total de la machine.

	Tous les deux problèmes seront résolus dans la version finale,
	qui devrait tourner sous tout système POSIX (Windows NT/2000
	inclus).


Q.      Est-ce qu'il n'est pas possible de crypter le mot de passe dans le
        fichier de configuration ?

A.      Oui, mais je ne vois pas pourquoi. De toutes les manières, le
        super-utilisateur sera capable de le récuperer.


Q.      Quand est-ce que la version finale sera disponible ?

A.      Pas plus d'un jour après qu'elle soit prête.


Partie II
Débits

Q.      Est-ce qu'il est possible que la cause du mauvais débit provienne de
        ma machine/ma configuration/mon système d'exploitation ?

A.      La valeur par défaut du MTU (taille maximale des paquets transmis)
        sous Windows 95/98 est loin d'être optimale pour une connexion
        par câble, ce qui peut effectivement baisser le débit maximum
        d'une connexion TCP. A part ce problème, qui ne concerne pas
        Linux, une installation avec les paramètres par défaut devrait
        fonctionner. Je vais essayer de créer une FAQ séparée pour les
        problèmes de performance réseau avec le modem câble sous
        Linux, le sujet étant assez vaste.


Q.      C'est quoi la valeur optimale du MTU sous Linux ?

A.      Avec un modem RTC, ça dépend surtout de la qualité da la ligne
	téléphonique, expérimentez, mais la valeur optimale sera
	probablement au moins 576 et jamais plus que 1500.

	Avec le câble : théoriquement la valeur optimale devrait être
	dans les 3000 octets (un peu moins en fait) pour qu'on puisse
	exploiter au maximum la plage réservée à une trame. Mais en
	réalité vous n'allez rien gagner après 1500 (qui est la valeur
	par défaut pour une interface Ethernet sous Linux). La raison
	est que 99% des serveurs sur Internet se trouvent ou passent
	par une connexion Ethernet quelque part et c'est à cet endroit
	que vos paquets seront fragmentés.

	Je voudrais que quelqu'un avec ADSL fasse une commentaire - de
	ce que je connais l'ADSL utilise une interface ppp pour la
	connection ce qui veut dire que la valeur par défaut n'est pas
	optimale (?)


Q.	Pourquoi bloquer les pings est-elle une mauvaise idée ?

A.      Bloquer les pings d'une façon brutale (en bloquant tous les
	messages ICMP), une technique de plus en plus courante, aura
	des conséquences négatives sur la performance de votre
	ligne. L'ICMP est un protocole assez compliqué et on ne s'est
	pas amusé à le développer juste pour que les pings puissent
	marcher. ICMP est utilisé aussi pour la négotiation
	automatique du MTU et pour les messages de type "Destination
	unreachable".

	Si vous insistez toujours pour bloquer les pings, la façon propre
	de le faire sous Linux se trouve dans les pseudo-fichiers
	/proc/sys/net/ipv4/icmp_echo*
