| Deutsch | English | Français | Nederlands | 日本語 | Svenska |

Options réseaux

Sommaire

• Introduction
• Connection permanente
• Connection intermittente par modem
• Ordinateurs derrière un firewall
• Fetching/Flushing via e-mail
• Partager les buffers au travers d'un réseau local
• Machines non connectées à l'internet

Introduction

Les informations qui suivent décrivent les différentes options proposées vous permettant d'alimenter votre client en blocs et de renvoyer le travail ainsi accompli aux serveurs de clefs de distributed.net. Veuillez, s'il-vous-plait lire attentivement la section correspondant à votre cas et suivre les instructions indiquées afin de configurer correctement votre connection au réseau de distributed.net.

Connection permanente à l'internet (Always Online mode)

Si , comme dans la plupart des cas , vous êtes connectés à l'internet au moyen d'un réseau local (mais pas derrière un firewall) , du câble , d'une ligne DSL ou RNIS, votre client devrait pouvoir communiquer correctement avec les proxies sans autre configuration spécifique.

ATTENTION: Si vous vous connectez à l'internet via une connection intermittente, faites bien attention de ne pas laisser le client dans sa configuration par défaut: 'Always Online mode'. Si vous oubliez ceci, votre client aura alors la possibilité d'établir à n'importe quel moment, et de son propre chef, une connection avec les proxies afin de mettre à jour lui même ses buffers. Pour éviter cela , vous devez sélectionner soit l'option Modem Dialup Lurk soit Modem Dialup Lurk-only, chacune de ces deux options étant décrite un peu plus bas.

Connection intermittente par modem

Si vous utilisez une connection par modem conventionnelle, votre client ne devrait avoir aucun problème de communication avec les serveurs de clés. Ici non plus , aucune modification de configuration n'est nécessaire, mis à part la sélection du bon mode de connection parmi les deux décrits juste ci-dessous:

• Modem Dialup Lurk: Cette option n'est sensée être utilisée que si vous disposez d'une connection par modem. Faites bien attention, dans ce mode, le client est sensé pouvoir se connecter à un proxy distributed.net à n'importe quel momment, et ce seul. Si vous ne voulez pas que le client établisse seul une connection à l'internet, alors que vous êtes déconnecté, vous devriez plutôt sélectionner l'option 'Modem Dialup Lurk-Only' (le client n'essaie pas de se connecter seul).

• Modem Dialup Lurk-Only (n'essaie pas de se connecter seul):Cette option est déstinée aux utilisateurs qui ne désirent pas que le client puisse se connecter à n'importe quel moment, de son propre chef, à un proxy distributed.net.

Ordinateurs derrière un firewall

Notez bien que même si vous êtes derrière un firewall, il se peut qu'il ne vous soit pas nécessaire de modifier la configuration du client. En effet, certains firewalls n'empêchent aucunement l'utilisation du client.

Cependant, même si vous remarquiez que votre firewall bloquait effectivement le port 2064, ne vous en faites pas, il existe plusieurs méthodes pour lui permettre tout de même d'établir une connection avec les proxies au travers de ce firewall. Chacune d'entre elles est décrite ci-dessous.

• La plus simple de ces méthodes est certainnement de modifier la configuration du firewall afin qu'il accepte des connections par le port 2064 (qui celui utiliser par défaut par le client) que ce soit directement , au travers d'un "datapipe" ou encore , si vous utilisez Wingate ou Internet Gate, via "direct port mapping". Chacune de ces options nécessite les privilèges de l'administrateur système. Si vous choisissez la deuxième, soyez sûr de bien configurer votre client de façon qu'il se connecte à l'adresse IP de votre firewall par le port que vous avez configuré pour rediriger ses requêtes vers l'extérieur.

• Une autre méthode efficace pour communiquer avec les proxies de distributed.net au travers d'un firewall, si vous n'avait pas la possibilité de modifier vous-même sa configuration, est d'utiliser le support SOCKS (si votre firewall le supporte, bien entendu). Pour configurer SOCKS, aller dans le menu de configuration "Buffer and Buffer Update Options" de votre client distributed.net, puis aller dans le sous-menu "Keyserver<->client connectivity options" et sélectionner "Firewall/proxy protocol". Si vous utilisez un proxy SOCKS4, choisissez "SOCKS4", ou choisissez "SOCKS5" si vous savez que votre firewall le supporte. Si vous n'êtes pas totalement sûr de la version de SOCKS que vous utilisez, sélectionner "SOCKS4" par défaut. Maintenant, veillez à bien indiquer le nom/adresse_ip du "firewall SOCKS"ainsi que le bon port. Si vous devez utiliser un login/mot_de_passe SOCKS , veillez à l'indiquer dans le champ approprié.

• La méthode de communication avec un firewall la plus commune est l'utilisation du support de proxy http du client. Aller dans le menu "Buffer and Buffer Update Options" du client distributed.net, puis dans le sous-menu "Keyserver<->client connectivity options" et sélectionner "Firewall/proxy protocol". La, spécifiez-y que vous voulez communiquer via un proxy HTTP. Indiquez ensuite le nom/adresse_ip du proxy HTTP dans le champ "Firewall hostname" ainsi que son numéro de port. Si vous rencontrez des problèmes d'encodage HTTP, vous devriez essayer d'utiliser l'option "Always use UUEnconding".

• Si les scénarios précédents ne fonctionnent pas ou ne l peuvent à cause de la configuration de votre Firewall, vous pouvez encore essayer, en dernier ressort, d'installer un proxy personnel (pproxy) sur la machine sur laquelle tourne le firewall. Notez cependant, que l'utilisation d'un pproxy n'est définitivement pas nécessaire à tout le monde et même déconseillé. Vous ne devriez l'utiliser que si vous savez vraiment ce que vous faites et que c'est votre ultime chance de connecter vos clients aux proxies de distributed.net au travers d'un firewall.

  Un proxy personnel recevra les connections de vos clients, en lieu et place des proxies de distributed.net, les approvisionnera, puis communiquera lui-même avec le réseau principal de proxies afin de transmettre/recevoir des blocs. L'installation d'un pproxy est simple et fiable; tout ce que vous avez à faire est de télécharger le proxy personnel correspondant à votre plateforme à proxies et de l'installer sur la machine servant de firewall. Vous devez ensuite configurer les clients, situés derrière le firewall, pour qu'il se connecte à cette machine. (Le nom/adresse_ip du proxy devra être indiqué dans la configuration du client dans le champ "keyserver" du menu "Buffer and Buffer Update Options", sous-menu "Keyserver<->client connectivity options". Bien entendu, vous devez être autorisé à installer et faire tourner le proxy personnel sur cette machine.

Enfin, voici une liste, non-exhaustive, de logiciels firewall connus pour fonctionner avec les clients distributed.net.

• Wingate 2.x+ (Win32): HTTP proxy, Direct port mapping, SOCKS 4 & 5.
• Internet Gate (OS/2): Direct port mapping
• Microsoft Proxy Server (WinNT): HTTP proxy
• Novell BorderManager (NetWare): HTTP proxy
• Squid (Unix): HTTP proxy
• AltaVista 97 (Unix/Win32): HTTP proxy
• Gauntlet Firewall: HTTP proxy

Fetching/Flushing via e-mail

Si vos clients ne peuvent envoyer/recevoir des blocs aux proxies de distributed.net au moyen des méthodes précédemment décrites, il existe encore une solution: envoyer et recevoir les blocs via e-mail.

Recevoir des blocs par e-mail:

1. Envoyer un mail à fetch@distributed.net avec les deux lignes suivantes dans le corps du message:
   
   blocksize=[nombre entre 28 et 33]
   numblocks=[nombre entre 1 et 500]
   
   Dans les minutes qui suivent, vous devriez recevoir un message de réponse contenant le nombre et la taille des blocs contenu par le fichier joint "buff-in.rc5".
   
   Note: Pour recevoir des blocs du projet OGR, incluez a n'importe quel endroit de votre message "contest=OGR".
2. Arreter le client.
3. Eventuellement, renommer le fichier buff-in.rc5 du répertoire dnetc comme vous l'avez indiquez dans le menu de configuration 'Buffer and buffer update options' section 4 'Checkpoint Filename'.
4. Extraire le fichier joint dans le répertoire d'où est exécuté le client distributed.net.
5. Redémarrer le client.

Ceci doit avoir pour effet de mettre à jour le nombre de blocs disponibles pour votre client. Ce nombre doit être incréménter du nombre exact indiqué dans le mail que vous avez reçu.

Renvoyer les blocs complétés par e-mail:

1. Envoyer un mail à flush@distributed.net avec le fichier "buff-out.rc5" comme pièce jointe soit au format uuencode soit codé en MIME64. Vous recevrez alors un accusé de réception vous indiquant que votre envoi c'est bien passé quelques minutes plus tard.
2. Effacer le fichier buff-out.rc5 afin de ne pas accidentellement envoyer deux fois une partie de son contenu.

Partager les buffers au travers d'un réseau local

Si vous désirez utiliser le client sur plusieurs ordinateurs à partir d'un disque réseau partagé, vous avez deux solutions. Par défaut, le client recherche un fichier .ini (où les informations de configuration du client sont stockées) portant le même nom que le client. Dans le cas où votre client est nommé dnetc il recherchera les informations de configuration dans un fichier appelé dnetc.ini. Une solution serait alors de créer plusieurs copies du client, chacune avec un nom différent; un nom par configurations requises. Une autre solution est d'inclure la variable d'environnement RC5INI dans la séquence de boot de chaque ordinateur. Le client utilisera alors en priorité les informations de configuration indiquées dans le fichier pointé par RC5INI. Dans ce cas, vous n'avez besoin que d'une seule copie du logiciel client, mais vous pouvez avoir plusieurs fichiers .ini différents, un par type de configuration nécessaire.

Machines non connectées à l'internet

Il est possible de faire tourner le client sur des machines qui ne sont jamais connectées à l'internet grâce à l'utilisation d'une disquette opur déplacer les fichiers de buffering entre ces machines et d'autres qui sont, elles, connectées à l'internet et peuvent envoyer et recevoir ces buffers. Ce procédé est connu sous le nom de "SneakerNetting" et est détaillé ci-dessous.

Instructions pour le "SneakerNetting"

Afin de simplifier au maximum ses instructions, nous admettrons que "laptop" désigne un ordinateur déconnecté/pas_en_réseau. Le mode d'emploi suivant assume également que vous utilisez Microsoft Windows, la méthode étant théoriquement transposable à n'importe quelle plateforme. Les buffers sont ici génériquement nommés buff-in.rc5 et buff-out.rc5 mais il est évident que la méthode suivante fonctionne également avec les autres projets, tel OGR en remplaçant simplement .rc5 par .ogr.

1. Télécharger le client et l'installer sur le laptop.
2. Arrêter le client de la machine connectée à l'internet.
3. Utiliser ce dernier pour récupérer un nouveau fichier buff_in.rc5
4. DEPLACER buff-in.rc5 sur la disquette.
5. Redémarrer le client connecté.
6. Insérer la disquette dans le laptop.
7. Démarrer le client du laptop en usant de l'option "-import [nom_du_buffer]".
8. Le client du laptop importera le fichier de buffering.
9. DEPLACER buff-out.rc5 du laptop vers la disquette.
10. Démarrer le client du laptop.
11. Insérer la disquette dans la machine connecté à l'internet.
12. Arrêter le client connecté.
13. Faites bien attention à d'abord 'flusher' le client connecté.
14. DEPLACER buff-out.rc5 de la disquette vers la machine connectée.
15. Démarrer le client connecté.
16. Et ainsi de suite...

© Copyright distributed.net 1997-2008 - All rights reserved
last modified: 5-Sep-2007

tar pit