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

Nätverksval

Innehåll

• Introduktion
• Permanenta anslutningar
• Uppringda förbindelser via modem
• Datorer bakom brandväggar
• Hur man gör Fetch/Flush via e-mail
• Hur man delar buffert-filer på lokala nätverk
• Maskiner utan internetaccess

Introduktion

Följande information beskriver de olika möjligheter som finns för att kunna ge klienter arbete och rapportera resultat tillbaka till distributed.nets huvudservrar. Läs noga igenom den del nedan som bäst beskriver din situation och följ instruktioner för hur du konfigurerar din klient därefter.

Permanenta anslutningar ("Always Online")

Om du använder en konventionell permanent anslutning genom ett lokalt nätverk (LAN) (ej bakom en brandvägg), kabel, DSL eller ISDN, kommer klienten att kommunicera med våra servrar utan någon som helst ändring i nätverkskommunikationsvalen i klienternas inställning. Låt mao. alla inställningar vara som de är.

Varning: Om du ansluter till Internet via en uppringd förbindelse, se till att du inte låter klienten vara i läget "Always Online". Annars kommer klienten att konstant försöka upprätthålla en förbindelse med huvudservrarna. Välj därför "Modem Dialup Lurk" eller "Modem Dialup Lurk-Only" enligt beskrivningen nedan.

Uppringd förbindelse ("Modem dial-up")

Om du använder en konventionell uppringd förbindelse, kommer klienten normalt sett att kommunicera med servrarna utan några speciella inställningar som helst. Det enda du ska tänka på är att ändra anslutningsläget från "Online Always" till någon av anslutningsmetoderna nedan:

• Modem Dialup Lurk: Den här inställningen används om du har en uppringd förbindelse till Internet. Var försiktig! I det här läget kommer klienten att försöka etablera en förbindelse med servrarna med jämna mellanrum. Om du inte vill att ditt modem automatiskt ska ringa upp när du är offline, välj istället "Modem Dialup Lurk-Only (don't trigger autodial)".

• Modem Dialup Lurk-Only (don't trigger autodial): Den här inställningen används för modemanvändare som inte vill att klienten ska försöka ansluta till Internet hela tiden. Klienten kommer att kontrollera om du är online innan den försöker skicka och ta emot data till och från servrarna.

Datorer bakom brandväggar

Om din maskin står bakom en brandvägg, är det i många fall inte nödvändigt att göra ändringar i nätverkskonfigurationen. Många brandväggsmiljöer låter maskiner som står innanför kommunicera obehindrat.

Om det visar sig att din brandvägg blockerar port 2064, finns det flera vägar att komma runt det här problemet. Varje situation beskrivs i detalj nedan:

• Den bästa lösningen är att se till att brandväggen tillåter kommunikation på port 2064 (porten som klienterna kommunicerar med distributed.net:s servrar på), antingen direkt eller genom en "datapipe" eller om du använder WinGate eller Internet Gate, via "direkt portmappning". Alla dessa lösningar kräver administratörsåtkomst till brandväggen. Om du väljer det andra valet, tänk på att konfigurera dina klienter så att de kommunicerar med brandväggens IP-adress på den port som du har konfigurerat den till att omdirigera ut på.

• Den näst bästa lösningen för att kommunicera med distributed.nets servrar genom en brandvägg, om du inte kan ändra i brandväggens konfigurering, är via SOCKS-stöd (om din brandvägg stödjer det dvs.) För att konfigurera SOCKS, gå in i "Buffer and Buffer Update Options" i klientens konfigurering, sedan i "Keyserver<->client connectivity options"-menyn, och välj sedan "Firewall/proxy protocol". Om du använder en SOCKS4-proxy, välj "SOCKS4", eller välj "SOCKS5" om du vet att din brandvägg stödjer det. Om du inte vet vilken version av SOCKS som används, välj SOCKS4. Nu får du fler val att fylla i. Fyll i brandväggens namn/IP-adress, och se till att de pekar på just den SOCKS-proxy som du kommer att kommunicera genom. Om du måste använda användarnamn och lösenord för SOCKS, ange det i motsvarande fält.

• Den mest kompatibla brandväggsmetoden är att använda http-proxy-supporten i klienten. Gå in i "Buffer and Buffer Update Options" på klienten, välj därefter "Keyserver<->client connectivity options" och sedan "Firewall/proxy protocol". Väl inne, ange att du vill kommunicera via en HTTP-proxy. Ange namnet/IP-adressen på den HTTP-proxy du använder under "Firewall hostname" och det portnummer som används. Om du har problem med HTTP-kodning, prova att använda flaggan "Always use UUEncoding".

• Om de tidigare nämna scenariona inte fungerar med din brandvägg, kan du försöka med att sätta upp en personlig proxy-server på maskinen som kör brandväggen. Kom ihåg att inte vem som helst behöver köra en personlig proxy-server. Vi rekommenderar det inte heller. Kör bara en personlig proxyserver om du är medveten om dina begränsningar, och att du inte har något annat val för dina klienter att kommunicera med distributed.net:s maskiner än genom att köra en personlig proxyserver.

  En personlig proxyserver tar emot klienternas förfrågningar, buffrar dem och kommunicerar med distributed.nets servrar för att skicka och ta emot block. Uppsättningen av en personlig proxyserver är enkel och stabil, att du behöver göra är att tanka hem programmet på proxies och sätta upp den på den maskinen som fungerar som brandvägg. Därefter sätter du upp alla klienterna bakom brandväggen att ansluta till den här maskinen istället för till distributed.net. (Namnet eller adressen på proxyservern anges i fältet "keyserver" under "Buffer and Buffer Update Options") och under "Keyserver<->client connectivity options". Naturligtvis måste du ha rättigheter att köra proxyservern på den maskin som är tänkt.

Till sist följer en lista över brandväggsmjukvara som vi vet fungerar med distributed.net:s klienter

• Wingate 2.x+ (Win32): HTTP proxy, Direct port mapping, SOCKS 4 & 5.
• Internet Gate (OS/2): Direkt portmappning
• 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

Skicka/Ta emot via e-mail

Om du inte kan skicka (flush) eller ta emot (fetch) block till/från distributed.net via någon av metoderna ovan, finns det även möjlighet att skicka och ta emot arbete via email.

För att ta emot arbete via email:

1. Skicka ett mail till fetch@distributed.net med följande två rader i själva meddelandetexten:
   
   blocksize=[nummer mellan 28 och 31]
   numblocks=[nummer mellan 1 och 500]
   
   Inom några minuter ska du få tillbaka ett mail med ett attachment vid namn "buff-in.rc5". Den buffertfilen innehåller det antal block med max den storlek du angav i det första mailet.
   
   Observera: För att begära OGR-nycklar, lägg till "contest=OGR" någonstans i ditt mail.
2. Stoppa klienten.
3. Döp om filen buff-in.rc5 i dnetc-biblioteket till det filnamn du har angivit i konfigurationsmenyn 'Buffer and buffer update options' val 4 'Checkpoint Filename'.
4. Extrahera attachmentet från ditt mailprogram till biblioteket där du kör dnetc-klienten.
5. Starta klienten igen.

Det här gör att det nya arbetet som du precis fick kommer att adderas till det återstående jobb-blocken som din klient redan arbetar på.

För att skicka färdiga block via email:

1. Skicka ett mail till flush@distributed.net med filen "buff-out.rc5" attachad antingen uukodad eller MIME64-kodad. Om allt gick riktigt till kommer du att få tillbaka ett "bekräftelsebrev" inom några minuter.
2. Radera filen buff-out.rc5 så att du av misstag skickar delar av den igen nästa gång du "flushar".

Hur man delar buffertfiler på lokala nätverk (LAN)

Om du vill köra klienten på flera datorer från en utdelad nätverksenhet, finns det flera möjligheter. Som standard letar klienterna efter en .ini-fil (där klientkonfigureringen finns lagrad) med samma namn som klienten. Så om din klient t.ex. kallas för dnetc letar den efter en konfigurationsfil som heter dnetc.ini. En lösning kan vara att skapa flera kopior av klienten, var och en med ett unikt namn; en för varje konfigurering som krävs. En annan möjlighet är att sätta miljövariabeln RC5INI i varje dators startuppsekvens. Klienten kommer att leta efter konfigureringsinformationen i den konfigureringsfil som RC5INI pekar på. På det här sättet behöver du bara en kopia av klientprogramvaran, men du kan ha flera .ini-filer, en för varje konfiguration du behöver.

Maskiner utan internetaccess

Det är möjligt att låta maskiner som aldrig ansluter till internet att köra klienten, genom att använda disketter för att flytta buffertfiler mellan dessa maskiner och maskiner som ansluter till internet, och därigenom använda de sistnämna för att fetcha och flusha block. Den här metoden kallas "SneakerNetting" och beskrivs nedan.

Hur man gör "SneakerNetting"

För att förenkla situationen, anta att "laptop" nedan menas maskinen utan internetaccess. Följande situation antar också att du kör Microsoft Windows, men i teorin är det samma för alla plattformar. Buffertfilerna kallas för buff-in.rc5 och buff-out.rc5 men samma metod kan användas för t.ex. OGR-projektet genom att byta ut bokstäverna rc5 mot ogr i buffertfilnamnen nedan.

1. Tanka hem klienten och installera den på laptopen.
2. Stoppa nätverksklienten.
3. Använd nätverksklienten för att fetcha en ny buff-in.rc5
4. FLYTTA buff-in.rc5-filen till en diskett.
5. Starta den nätverkande klienten.
6. Flytta disketten till laptopen.
7. Kör igång laptopklienten med "-import [buffertfilnamn]" som tillägg.
8. Laptopen importerar buffertfilen.
9. FLYTTA buff-out.rc5 från laptopen till disketten.
10. Starta laptopklienten.
11. Ta disketten till nätverksmaskinen.
12. Stoppa nätverksklienten.
13. Gör flush mha. nätverksklienten.
14. FLYTTA buff-out.rc5-filen från disketten till nätverksmaskinen.
15. Starta nätverksmaskinen.
16. Repetera.

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

tar pit