Probleme - Revision history

Theodorescu: /* Skalierbarkeit */

2006-02-14T13:35:24Z

Skalierbarkeit

← Older revision		Revision as of 13:35, 14 February 2006
Line 20:		Line 20:
	Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>		Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>
	Um zu verhindern, dass diese Störungen durch überlastete Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>		Um zu verhindern, dass diese Störungen durch überlastete Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>
	Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Desweiteren werden Verbindungen zu überlasteten Servents beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[~~Ultrapeers und Leafs\|~~Gnutella 0.6]]. <br>		Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Desweiteren werden Verbindungen zu überlasteten Servents beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Gnutella 0.6\|Ultrapeers und Leafs]]. <br>
	Außerdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>		Außerdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>
	<br>		<br>

Theodorescu: /* Skalierbarkeit */

2006-02-14T13:34:52Z

Skalierbarkeit

← Older revision		Revision as of 13:34, 14 February 2006
Line 20:		Line 20:
	Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>		Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>
	Um zu verhindern, dass diese Störungen durch überlastete Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>		Um zu verhindern, dass diese Störungen durch überlastete Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>
	Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Desweiteren werden Verbindungen zu überlasteten Servents beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers & Leafs]]. <br>		Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Desweiteren werden Verbindungen zu überlasteten Servents beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers und Leafs\|Gnutella 0.6]]. <br>
	Außerdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>		Außerdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>
	<br>		<br>

Theodorescu: /* Skalierbarkeit */

2006-02-14T13:32:54Z

Skalierbarkeit

← Older revision		Revision as of 13:32, 14 February 2006
Line 20:		Line 20:
	Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>		Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>
	Um zu verhindern, dass diese Störungen durch überlastete Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>		Um zu verhindern, dass diese Störungen durch überlastete Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>
	Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Desweiteren werden Verbindungen zu überlasteten Servents beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers]] ~~und~~ [[Leafs]]. <br>		Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Desweiteren werden Verbindungen zu überlasteten Servents beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers & Leafs]]. <br>
	Außerdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>		Außerdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>
	<br>		<br>
Line 26:		Line 26:
	<br>		<br>
	<br>		<br>

	==Entwicklung==		==Entwicklung==
	Die Entwicklung von Gnutella war lange Zeit nicht einheitlich und es gab auch keine Organisation, die daran etwas ändern konnte. Daher gab es viele Clients mit unterschiedlichen Implemenationen, was natürlich nicht zur Effektivität des Gnet beitrug. <br>		Die Entwicklung von Gnutella war lange Zeit nicht einheitlich und es gab auch keine Organisation, die daran etwas ändern konnte. Daher gab es viele Clients mit unterschiedlichen Implemenationen, was natürlich nicht zur Effektivität des Gnet beitrug. <br>

Arnold at 14:02, 5 February 2006

2006-02-05T14:02:16Z

Arnold at 15:24, 4 February 2006

2006-02-04T15:24:07Z

← Older revision		Revision as of 15:24, 4 February 2006
Line 15:		Line 15:
	<br>		<br>
	[[Gnutella\|zurück zum Index]]		[[Gnutella\|zurück zum Index]]
			<br>
	<br>		<br>
	==Skalierbarkeit==		==Skalierbarkeit==
Line 21:		Line 22:
	Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Verbindungen zu überlasteten Servents werden beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers]] und [[Leafs]]. <br>		Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Verbindungen zu überlasteten Servents werden beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers]] und [[Leafs]]. <br>
	Ausserdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>		Ausserdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>
			<br>
			[[Gnutella\|zurück zum Index]]
			<br>
	<br>		<br>
	==Entwicklung==		==Entwicklung==
	Die Entwicklung von Gnutella war lange Zeit nicht einheitlich und es gab auch keine Organisation, die daran etwas ändern konnte. Daher gab es viele Clients mit unterschiedlichen Implemenationen, was natürlich nicht zur Effektivität des Gnet beitrug. <br>		Die Entwicklung von Gnutella war lange Zeit nicht einheitlich und es gab auch keine Organisation, die daran etwas ändern konnte. Daher gab es viele Clients mit unterschiedlichen Implemenationen, was natürlich nicht zur Effektivität des Gnet beitrug. <br>
	Letztendlich wurde versucht mit dem [http://www.the-gdf.org/wiki/index.php?title=Main_Page Gnutella Developer Forum (GDF)] eine Basis zur gemeinsame Entwicklung von Ideen bereitzustellen.		Letztendlich wurde versucht mit dem [http://www.the-gdf.org/wiki/index.php?title=Main_Page Gnutella Developer Forum (GDF)] eine Basis zur gemeinsame Entwicklung von Ideen bereitzustellen.
			<br>
			[[Gnutella\|zurück zum Index]]

Arnold at 15:23, 4 February 2006

2006-02-04T15:23:09Z

← Older revision		Revision as of 15:23, 4 February 2006
Line 13:		Line 13:
	Um den Traffic im Gnet zu verringern und unnötige Query Hits zu vermeiden, die wahrscheinlich ein Download Request nach sich ziehen würden, wird bei neueren Clients nur noch ein Query Hit gesendet, wenn Ressourcen für ein Upload bereitgestellt werden. Ausserdem senden Servents ein Busysignal wenn kein Ressourcen verfügabr sind. Dadurch versucht der anfragende Servent es zu einem späteren Zeitpunkt noch einmal. <br>		Um den Traffic im Gnet zu verringern und unnötige Query Hits zu vermeiden, die wahrscheinlich ein Download Request nach sich ziehen würden, wird bei neueren Clients nur noch ein Query Hit gesendet, wenn Ressourcen für ein Upload bereitgestellt werden. Ausserdem senden Servents ein Busysignal wenn kein Ressourcen verfügabr sind. Dadurch versucht der anfragende Servent es zu einem späteren Zeitpunkt noch einmal. <br>
	Das hatte auch gleichzeitig den Effekt, dass User länger online blieben um ihre Downloads zu vervollständigen und somit auch länger ihre Uploads dem Gnet zur Verfügung stellten. <br>		Das hatte auch gleichzeitig den Effekt, dass User länger online blieben um ihre Downloads zu vervollständigen und somit auch länger ihre Uploads dem Gnet zur Verfügung stellten. <br>
			<br>
			[[Gnutella\|zurück zum Index]]
	<br>		<br>
	==Skalierbarkeit==		==Skalierbarkeit==

Arnold at 15:21, 4 February 2006

2006-02-04T15:21:28Z

← Older revision		Revision as of 15:21, 4 February 2006
Line 17:		Line 17:
	Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>		Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>
	Um zu verhindern, dass diese Störungen durch überlastet Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>		Um zu verhindern, dass diese Störungen durch überlastet Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>
	Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Verbindungen zu überlasteten Servents werden beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers]] und [[Leafs]].		Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Verbindungen zu überlasteten Servents werden beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers]] und [[Leafs]]. <br>
	Ausserdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet.		Ausserdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>
			<br>
			==Entwicklung==
			Die Entwicklung von Gnutella war lange Zeit nicht einheitlich und es gab auch keine Organisation, die daran etwas ändern konnte. Daher gab es viele Clients mit unterschiedlichen Implemenationen, was natürlich nicht zur Effektivität des Gnet beitrug. <br>
			Letztendlich wurde versucht mit dem [http://www.the-gdf.org/wiki/index.php?title=Main_Page Gnutella Developer Forum (GDF)] eine Basis zur gemeinsame Entwicklung von Ideen bereitzustellen.

Arnold at 15:15, 4 February 2006

2006-02-04T15:15:21Z

← Older revision		Revision as of 15:15, 4 February 2006
Line 17:		Line 17:
	Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>		Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>
	Um zu verhindern, dass diese Störungen durch überlastet Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>		Um zu verhindern, dass diese Störungen durch überlastet Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>
			Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Verbindungen zu überlasteten Servents werden beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers]] und [[Leafs]].
	~~Um dies zu erreichen~~ werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet.		Ausserdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet.

Arnold at 15:07, 4 February 2006

2006-02-04T15:07:08Z

← Older revision		Revision as of 15:07, 4 February 2006
Line 12:		Line 12:
	Seitdem ist es bei den meistens Clients daher notwendig Uploads bereitzustellen, wenn man Dateien herunterladen möchte. <br>		Seitdem ist es bei den meistens Clients daher notwendig Uploads bereitzustellen, wenn man Dateien herunterladen möchte. <br>
	Um den Traffic im Gnet zu verringern und unnötige Query Hits zu vermeiden, die wahrscheinlich ein Download Request nach sich ziehen würden, wird bei neueren Clients nur noch ein Query Hit gesendet, wenn Ressourcen für ein Upload bereitgestellt werden. Ausserdem senden Servents ein Busysignal wenn kein Ressourcen verfügabr sind. Dadurch versucht der anfragende Servent es zu einem späteren Zeitpunkt noch einmal. <br>		Um den Traffic im Gnet zu verringern und unnötige Query Hits zu vermeiden, die wahrscheinlich ein Download Request nach sich ziehen würden, wird bei neueren Clients nur noch ein Query Hit gesendet, wenn Ressourcen für ein Upload bereitgestellt werden. Ausserdem senden Servents ein Busysignal wenn kein Ressourcen verfügabr sind. Dadurch versucht der anfragende Servent es zu einem späteren Zeitpunkt noch einmal. <br>
	Das hatte auch gleichzeitig den Effekt, dass User länger online blieben um ihre Downloads zu vervollständigen und somit auch länger ihre Uploads dem Gnet zur Verfügung stellten.		Das hatte auch gleichzeitig den Effekt, dass User länger online blieben um ihre Downloads zu vervollständigen und somit auch länger ihre Uploads dem Gnet zur Verfügung stellten. <br>
			<br>
			==Skalierbarkeit==
			Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>
			Um zu verhindern, dass diese Störungen durch überlastet Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>
			Um dies zu erreichen werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet.

Arnold at 14:49, 4 February 2006

2006-02-04T14:49:36Z

← Older revision		Revision as of 14:49, 4 February 2006
Line 1:		Line 1:
	Die erste Version von Gnutella (v0.4) hatte in den drei folgenden Bereichen wesentliche Probleme: <br>		Die erste Version von Gnutella (v0.4) hatte in den drei folgenden Bereichen wesentliche Probleme: <br>
	[[#Download]] <br>		*[[#Download\|Download]] <br>
	[[#Skalierbarkeit]] <br>		*[[#Skalierbarkeit\|Skalierbarkeit]] <br>
	[[#Entwicklung]] <br>		*[[#Entwicklung\| Entwicklung]] <br>
	<br>		<br>
	==Download==		==Download==
Line 9:		Line 9:
	Deshalb ging man dazu über, User zu Blockieren, die Webinterfaces benutzten.		Deshalb ging man dazu über, User zu Blockieren, die Webinterfaces benutzten.

	Ein weiteres Problem war das Userverhalten. Viele benutzten zwar Clients, stellten aber trotzdem nichts zum Upload bereit oder waren nur kurz mit dem Gnet verbunden, so dass angefangene Uploads nicht beendet werden konnten.		Ein weiteres Problem war das Userverhalten. Viele benutzten zwar Clients, stellten aber trotzdem nichts zum Upload bereit oder waren nur kurz mit dem Gnet verbunden, so dass angefangene Uploads nicht beendet werden konnten. <br>
			Seitdem ist es bei den meistens Clients daher notwendig Uploads bereitzustellen, wenn man Dateien herunterladen möchte. <br>
	Um das zu verhindern
			Um den Traffic im Gnet zu verringern und unnötige Query Hits zu vermeiden, die wahrscheinlich ein Download Request nach sich ziehen würden, wird bei neueren Clients nur noch ein Query Hit gesendet, wenn Ressourcen für ein Upload bereitgestellt werden. Ausserdem senden Servents ein Busysignal wenn kein Ressourcen verfügabr sind. Dadurch versucht der anfragende Servent es zu einem späteren Zeitpunkt noch einmal. <br>

			Das hatte auch gleichzeitig den Effekt, dass User länger online blieben um ihre Downloads zu vervollständigen und somit auch länger ihre Uploads dem Gnet zur Verfügung stellten.
	Servents senden Query Hit nur, wenn Ressourcen für Upload bereitgestellt werden
	Servents senden bei Dowloadanfrage Busysignal, wenn keine Ressourcen verfügbar; anfragender Servent versucht es zu einem späteren Zeitpunkt noch einmal
	User bleiben länger online, um Downloads zu vervollständigen

← Older revision		Revision as of 14:02, 5 February 2006
Line 5:		Line 5:
	<br>		<br>
	==Download==		==Download==
	Beim Versuch sich Dateien aus dem Gnutella Netzwerk herunterzuladen kam es oft zu Fehlern, so dass der Download nicht gestartet oder beendet werden konnte. Das lag einerseits an schlecht programmierten Clients, die die Vorgaben des Gnutella Netzwerks zum Verhalten eines Clients nicht oder nur teilweise implementierten. <br>		Beim Versuch sich Dateien aus dem Gnutella Netzwerk herunterzuladen kam es oft zu Fehlern, so dass der Download nicht gestartet oder beendet werden konnte. Das lag einerseits an schlecht programmierten Clients, die die Vorgaben des Gnutella Netzwerks, zum Verhalten eines Clients, nicht oder nur teilweise implementierten. <br>
	Andererseits trugen die User wesentlich selbst dazu bei. Es gab eine wachsende Anzahl an Usern, die browserbasierte Suchdienste wie '''asiayeah.com''' und '''gnute.com''' verwendeten, um Dateien herunterzuladen und dadurch selber keine Dateien im Gnet anboten. Die Folge davon waren viele Download Anfragen, aber nur wenige Bereistellungen von Uploads. Eine Datei konnte man durch eine Suche im Gnet zwar finden, aber meistens nicht herunterladen oder man musste eine lange Wartezeit hinnehmen, da ~~der~~ anbietende ~~Servent~~ ~~seine~~ maximalen Uploads schon erreicht ~~hatte~~. <br>		Andererseits trugen die User wesentlich selbst dazu bei. Es gab eine wachsende Anzahl an Usern, die browserbasierte Suchdienste wie '''asiayeah.com''' und '''gnute.com''' verwendeten, um Dateien herunterzuladen und dadurch selber keine Dateien im Gnet anboten. Die Folge davon waren viele Download Anfragen, aber nur wenige Bereistellungen von Uploads. Eine Datei konnte man durch eine Suche im Gnet zwar finden, aber meistens nicht herunterladen oder man musste eine lange Wartezeit hinnehmen, da anbietende Servents ihre maximalen Uploads oft schon erreicht hatten. <br>
	Deshalb ging man dazu über, User zu Blockieren, die Webinterfaces benutzten.		Deshalb ging man dazu über, User zu Blockieren, die Webinterfaces benutzten.

	Ein weiteres Problem war das Userverhalten. Viele benutzten zwar Clients, stellten aber trotzdem nichts zum Upload bereit oder waren nur kurz mit dem Gnet verbunden, so dass angefangene Uploads nicht beendet werden konnten. <br>		Ein weiteres Problem war das Userverhalten. Viele benutzten zwar Clients, stellten aber trotzdem nichts zum Upload bereit oder waren nur kurz mit dem Gnet verbunden, so dass angefangene Uploads nicht beendet werden konnten. <br>
	Seitdem ist es bei den meistens Clients daher notwendig Uploads bereitzustellen, wenn man Dateien herunterladen möchte. <br>		Seitdem ist es bei den meistens Clients daher notwendig Uploads bereitzustellen, wenn man Dateien herunterladen möchte. <br>
	Um den Traffic im Gnet zu verringern und unnötige Query Hits zu vermeiden, die wahrscheinlich ein Download Request nach sich ziehen würden, wird bei neueren Clients nur noch ein Query Hit gesendet, wenn Ressourcen für ein Upload bereitgestellt werden. ~~Ausserdem~~ senden Servents ein Busysignal wenn kein Ressourcen ~~verfügabr~~ sind. Dadurch versucht der anfragende Servent es zu einem späteren Zeitpunkt noch einmal. <br>		Um den Traffic im Gnet zu verringern und unnötige Query Hits zu vermeiden, die wahrscheinlich ein Download Request nach sich ziehen würden, wird bei neueren Clients nur noch ein Query Hit gesendet, wenn Ressourcen für ein Upload bereitgestellt werden. Außerdem senden Servents ein Busysignal wenn kein Ressourcen verfügbar sind. Dadurch versucht der anfragende Servent nicht sofort ein Download zu starten, sonderen probiert es zu einem späteren Zeitpunkt noch einmal. <br>
	Das hatte auch gleichzeitig den Effekt, dass User länger online blieben um ihre Downloads zu vervollständigen und somit auch länger ihre Uploads dem Gnet zur Verfügung stellten. <br>		Das hatte auch gleichzeitig den Effekt, dass User länger online blieben um ihre Downloads zu vervollständigen und somit auch länger ihre Uploads dem Gnet zur Verfügung stellten. <br>
	<br>		<br>
Line 19:		Line 19:
	==Skalierbarkeit==		==Skalierbarkeit==
	Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>		Ein enormes Problem war die schlechte Skalierbarkeit von Gnutella. Im Mittel war das Gnet nur bei einer Anzahl von 400-800 Usern nutzbar. Bei einer größeren Anzahl von Useren trat das so genannte Modem-Bandwith-Barrier Problem auf. Dieses Problem entstand bei Usern mit Modem, deren nutzbare Bandbreite durch den Traffic des Gnet überschritten wurde, was zu Störungen im gesamten Gnet führte, da z.B. Query Hits nicht mehr weitergeleitet werden konnten. <br>
	Um zu verhindern, dass diese Störungen durch ~~überlastet~~ Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>		Um zu verhindern, dass diese Störungen durch überlastete Modems auftreten musste das Netzwerk strukturiert werden. Servents mit schneller Verbindung sollen daher überwiegend Verbindungen mit anderen 'schnellen' Servents aufbauen und den Kern des Netzwerks bilden. Servents mit langsamer Verbindung sollen hingegen an den Netzwerkrand, wo sie nicht viel Traffic zu verwalten haben. <br>
	Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Verbindungen zu überlasteten Servents ~~werden~~ beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers]] und [[Leafs]]. <br>		Um diese Strukturierung zu erreichen müssen User bei ihren Clients ihre Verbindungsgeschwindigkeit (T1, T3, ...) einstellen. Desweiteren werden Verbindungen zu überlasteten Servents beendet, was zur Folge hat, dass diese an den Netzwerkrand verschoben werden. Eine neuere Implementationsidee ist die Unterteilung der Servents in [[Ultrapeers]] und [[Leafs]]. <br>
	~~Ausserdem~~ werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>		Außerdem werden Implementationen wie [[Flow Control]], [[Ping Pong Schema]] und das [[Query Routing Protocol]] verwendet. <br>
	<br>		<br>
	[[Gnutella\|zurück zum Index]]		[[Gnutella\|zurück zum Index]]