Flow Control - Revision history

Arnold at 14:11, 5 February 2006

2006-02-05T14:11:45Z

← Older revision		Revision as of 14:11, 5 February 2006
Line 40:		Line 40:
	<br>		<br>
	Die Queues werdem nach dem Round-Robin Verfahren abgearbeitet, wodurch kein Nachrichtentyp den Traffic dominiert; was bei einer einzelnen Queue für alle Nachrichtentypen durchaus der Fall sein könnte. Desweiteren verwenden alle Queues außer der Query-Hit-Queue das LIFO Verfahren, dadurch werden Nachrichten nicht um eine konstante Zeit verzögert. Allerdings werden ältere Nachrichten, die bereits gequeuet wurden möglicherweise länger verzögert als beim, im Gnutella implementierten, Flow Control Modus. <br>		Die Queues werdem nach dem Round-Robin Verfahren abgearbeitet, wodurch kein Nachrichtentyp den Traffic dominiert; was bei einer einzelnen Queue für alle Nachrichtentypen durchaus der Fall sein könnte. Desweiteren verwenden alle Queues außer der Query-Hit-Queue das LIFO Verfahren, dadurch werden Nachrichten nicht um eine konstante Zeit verzögert. Allerdings werden ältere Nachrichten, die bereits gequeuet wurden möglicherweise länger verzögert als beim, im Gnutella implementierten, Flow Control Modus. <br>
	Für Query-Routing-Protocol Nachrichten sollte allerdings kein LIFO Verfahren angewandt und das Verwerfen sollte auch vermieden werden, da es wichtig ist, dass QRP Nachrichten in der richtigen Reihenfolge ankommen (siehe auch Query Routing Protocol<br>		Für Query-Routing-Protocol Nachrichten sollte allerdings kein LIFO Verfahren angewandt und das Verwerfen sollte auch vermieden werden, da es wichtig ist, dass QRP Nachrichten in der richtigen Reihenfolge ankommen (siehe auch [[Query Routing Protocol]])<br>
	<br>		<br>
	[[Gnutella\|zurück zum Index]]		[[Gnutella\|zurück zum Index]]

Arnold at 14:11, 5 February 2006

2006-02-05T14:11:02Z

← Older revision		Revision as of 14:11, 5 February 2006
Line 9:		Line 9:

	Im Flow Control Modus werden alle ankommenden Queries verworfen. <br>		Im Flow Control Modus werden alle ankommenden Queries verworfen. <br>
	Weiterzuleitende Nachrichten erhalten eine umso kleinere Priorität, desto mehr Hops(Servents) diese schon durchlaufen haben:		Weiterzuleitende Nachrichten erhalten eine umso kleinere Priorität, desto mehr Hops(Servents) diese schon durchlaufen haben.
	Allerdings wird bei Query Hits genau entgegengesetzt der Strategie für weiterzuleitende Nachrichten vorgegangen, da sonst der vorangegangene Aufwand umsonst gewesen ~~ist~~. <br>		Allerdings wird bei Query Hits genau entgegengesetzt der Strategie für weiterzuleitende Nachrichten vorgegangen, da sonst der vorangegangene Aufwand umsonst gewesen wäre. <br>
	<br>		<br>
	Reihenfolge der Nachrichten nach Priorität:		Reihenfolge der Nachrichten nach Priorität:
Line 36:		Line 36:
	Für jede Verbindung wird ein Buffer eingerichtet, der wiederum aus Queues besteht (eine für jeden Nachrichtentyp).		Für jede Verbindung wird ein Buffer eingerichtet, der wiederum aus Queues besteht (eine für jeden Nachrichtentyp).
	Die Queue für Query Hits wird nach dem GUID-Volumen sortiert, welches angibt wieviele Antworten auf ein Query gegeben wurden.		Die Queue für Query Hits wird nach dem GUID-Volumen sortiert, welches angibt wieviele Antworten auf ein Query gegeben wurden.
	Desto weniger Query Hits auf einen Query als Antwort eingehen, umso unpopulärer ist der Query Hit und wird dadurch priorisiert. Da es genügend Antworten auf einen populären Query gibt, können ~~diese~~ Query Hits notfalls verworfen werden, was bei unpopulären Querys aber dazu führen könnte, dass der anfragende Servent überhaupt keine Query Hits auf seine Anfrage bekommt. <br>		Desto weniger Query Hits auf einen Query als Antwort eingehen, umso unpopulärer ist der Query Hit und wird dadurch priorisiert. Da es genügend Antworten auf einen populären Query gibt, können die dazugehörenden Query Hits notfalls verworfen werden, was bei unpopulären Querys aber dazu führen könnte, dass der anfragende Servent überhaupt keine Query Hits auf seine Anfrage bekommt. <br>
	Alle anderen Queues sind zeitlich sortiert und neue Nachrichten stehen am Anfang. Wenn eine Queue voll ist, wird die letzte Nachricht verworfen und die neue eingefügt. <br>		Alle anderen Queues sind zeitlich sortiert und neue Nachrichten stehen am Anfang. Wenn eine Queue voll ist, wird die letzte Nachricht verworfen und die neue eingefügt. <br>
	<br>		<br>
	Die Queues werdem ~~dem~~ nach Round-Robin Verfahren abgearbeitet wodurch kein Nachrichtentyp den Traffic dominiert; was bei einer einzelnen Queue für alle Nachrichtentypen durchaus der Fall sein könnte. Desweiteren verwenden alle Queues ~~ausser~~ der Query-Hit-Queue das LIFO Verfahren, dadurch werden Nachrichten nicht um eine konstante Zeit verzögert. Allerdings werden ältere Nachrichten, die bereits gequeuet wurden, möglicherweise länger verzögert, als beim im Gnutella implementierten Flow Control Modus. <br>		Die Queues werdem nach dem Round-Robin Verfahren abgearbeitet, wodurch kein Nachrichtentyp den Traffic dominiert; was bei einer einzelnen Queue für alle Nachrichtentypen durchaus der Fall sein könnte. Desweiteren verwenden alle Queues außer der Query-Hit-Queue das LIFO Verfahren, dadurch werden Nachrichten nicht um eine konstante Zeit verzögert. Allerdings werden ältere Nachrichten, die bereits gequeuet wurden möglicherweise länger verzögert als beim, im Gnutella implementierten, Flow Control Modus. <br>
	Für Query-Routing-Protocol Nachrichten sollte allerdings kein LIFO Verfahren angewandt ~~werden~~ und das Verwerfen sollte auch vermieden, da es wichtig ist, dass QRP Nachrichten in der richtigen Reihenfolge ankommen<br>		Für Query-Routing-Protocol Nachrichten sollte allerdings kein LIFO Verfahren angewandt und das Verwerfen sollte auch vermieden werden, da es wichtig ist, dass QRP Nachrichten in der richtigen Reihenfolge ankommen (siehe auch Query Routing Protocol<br>
	<br>		<br>
	[[Gnutella\|zurück zum Index]]		[[Gnutella\|zurück zum Index]]

Arnold at 16:31, 4 February 2006

2006-02-04T16:31:47Z

← Older revision		Revision as of 16:31, 4 February 2006
Line 40:		Line 40:
	<br>		<br>
	Die Queues werdem dem nach Round-Robin Verfahren abgearbeitet wodurch kein Nachrichtentyp den Traffic dominiert; was bei einer einzelnen Queue für alle Nachrichtentypen durchaus der Fall sein könnte. Desweiteren verwenden alle Queues ausser der Query-Hit-Queue das LIFO Verfahren, dadurch werden Nachrichten nicht um eine konstante Zeit verzögert. Allerdings werden ältere Nachrichten, die bereits gequeuet wurden, möglicherweise länger verzögert, als beim im Gnutella implementierten Flow Control Modus. <br>		Die Queues werdem dem nach Round-Robin Verfahren abgearbeitet wodurch kein Nachrichtentyp den Traffic dominiert; was bei einer einzelnen Queue für alle Nachrichtentypen durchaus der Fall sein könnte. Desweiteren verwenden alle Queues ausser der Query-Hit-Queue das LIFO Verfahren, dadurch werden Nachrichten nicht um eine konstante Zeit verzögert. Allerdings werden ältere Nachrichten, die bereits gequeuet wurden, möglicherweise länger verzögert, als beim im Gnutella implementierten Flow Control Modus. <br>
	Für Query-Routing-Protocol Nachrichten sollte allerdings kein LIFO Verfahren angewandt werden und das Verwerfen sollte auch vermieden, da es wichtig ist, dass QRP Nachrichten in der richtigen Reihenfolge ankommen		Für Query-Routing-Protocol Nachrichten sollte allerdings kein LIFO Verfahren angewandt werden und das Verwerfen sollte auch vermieden, da es wichtig ist, dass QRP Nachrichten in der richtigen Reihenfolge ankommen<br>
			<br>
			[[Gnutella\|zurück zum Index]]
			<br>
			<br>

Arnold at 16:30, 4 February 2006

2006-02-04T16:30:25Z

← Older revision		Revision as of 16:30, 4 February 2006
Line 39:		Line 39:
	Alle anderen Queues sind zeitlich sortiert und neue Nachrichten stehen am Anfang. Wenn eine Queue voll ist, wird die letzte Nachricht verworfen und die neue eingefügt. <br>		Alle anderen Queues sind zeitlich sortiert und neue Nachrichten stehen am Anfang. Wenn eine Queue voll ist, wird die letzte Nachricht verworfen und die neue eingefügt. <br>
	<br>		<br>
			Die Queues werdem dem nach Round-Robin Verfahren abgearbeitet wodurch kein Nachrichtentyp den Traffic dominiert; was bei einer einzelnen Queue für alle Nachrichtentypen durchaus der Fall sein könnte. Desweiteren verwenden alle Queues ausser der Query-Hit-Queue das LIFO Verfahren, dadurch werden Nachrichten nicht um eine konstante Zeit verzögert. Allerdings werden ältere Nachrichten, die bereits gequeuet wurden, möglicherweise länger verzögert, als beim im Gnutella implementierten Flow Control Modus. <br>
	abarbeiten der Queues nach Round-Robin Verfahren
			Für Query-Routing-Protocol Nachrichten sollte allerdings kein LIFO Verfahren angewandt werden und das Verwerfen sollte auch vermieden, da es wichtig ist, dass QRP Nachrichten in der richtigen Reihenfolge ankommen
	kein Nachrichtentyp dominiert Verkehr
	LIFO Verfahren für alle Queues außer Query-Hit-Queue verwenden
	Nachrichten werden nicht um konstante Zeit verzögert
	für Query-Routing-Protocol Nachrichten sollte allerdings kein
	LIFO Verfahren angewandt werden; auch Verwerfen vermeiden
	wichtig, dass QRP Nachrichten in richtiger Reihenfolge ankommen

Arnold at 16:20, 4 February 2006

2006-02-04T16:20:06Z

← Older revision		Revision as of 16:20, 4 February 2006
Line 33:		Line 33:
	*Verhindern, dass ein Nachrichtentyp den Verkehr dominiert		*Verhindern, dass ein Nachrichtentyp den Verkehr dominiert
	*Favorisierung von weniger populären Query Hits <br>		*Favorisierung von weniger populären Query Hits <br>
			<br>
			Für jede Verbindung wird ein Buffer eingerichtet, der wiederum aus Queues besteht (eine für jeden Nachrichtentyp).
			Die Queue für Query Hits wird nach dem GUID-Volumen sortiert, welches angibt wieviele Antworten auf ein Query gegeben wurden.
			Desto weniger Query Hits auf einen Query als Antwort eingehen, umso unpopulärer ist der Query Hit und wird dadurch priorisiert. Da es genügend Antworten auf einen populären Query gibt, können diese Query Hits notfalls verworfen werden, was bei unpopulären Querys aber dazu führen könnte, dass der anfragende Servent überhaupt keine Query Hits auf seine Anfrage bekommt. <br>
			Alle anderen Queues sind zeitlich sortiert und neue Nachrichten stehen am Anfang. Wenn eine Queue voll ist, wird die letzte Nachricht verworfen und die neue eingefügt. <br>
			<br>
			abarbeiten der Queues nach Round-Robin Verfahren
			kein Nachrichtentyp dominiert Verkehr
			LIFO Verfahren für alle Queues außer Query-Hit-Queue verwenden
			Nachrichten werden nicht um konstante Zeit verzögert
			für Query-Routing-Protocol Nachrichten sollte allerdings kein
			LIFO Verfahren angewandt werden; auch Verwerfen vermeiden
			wichtig, dass QRP Nachrichten in richtiger Reihenfolge ankommen

Arnold at 16:09, 4 February 2006

2006-02-04T16:09:52Z

@@ Line 1: / Line 1: @@
 Um Überlastungen eines Servents zu vermeiden wurde bei der neueren Version von Gnutella (v0.6) ein Algorithmus zur Flow Control implementiert. <br>
 Der einfachste Ansatz wäre, die Verbindung zu schliessen, wenn zu viel Bandbreite beansprucht wird; besser ist es jedoch, weiterzuleitende Nachrichten zu verwerfen um der Traffic zu verringern. Somit würden aber auch Query Hits verworfen, wodurch vorangegangene Querys umsonst Traffic im Gnet verursacht hätten. <br>
@@ Line 9: / Line 10: @@
 Im Flow Control Modus werden alle ankommenden Queries verworfen. <br>
 Weiterzuleitende Nachrichten erhalten eine umso kleinere Priorität, desto mehr Hops(Servents) diese schon durchlaufen haben:
-Allerdings wird bei Query Hits genau entgegengesetzt der Strategie für weiterzuleitende Nachrichten vorgegangen, da sonst der vorangegangener Aufwand umsonst gewesen ist. <br>
+Allerdings wird bei Query Hits genau entgegengesetzt der Strategie für weiterzuleitende Nachrichten vorgegangen, da sonst der vorangegangene Aufwand umsonst gewesen ist. <br>
 <br>
 Reihenfolge der Nachrichten nach Priorität:
  Push, Query Hit, Pong, Query, Ping
 <br>
-Individuelle Nachrichten werden im FC Modus bevorzugt.
+Individuelle Nachrichten werden im FC Modus bevorzugt. <br>

Arnold at 15:58, 4 February 2006

2006-02-04T15:58:54Z

← Older revision		Revision as of 15:58, 4 February 2006
Line 6:		Line 6:
	*:->solange bis wieder unter 25%		*:->solange bis wieder unter 25%
	*Größe der Queue sollte mindestens 150% der max. zulässigen Nachrichtengröße sein		*Größe der Queue sollte mindestens 150% der max. zulässigen Nachrichtengröße sein

			Im Flow Control Modus werden alle ankommenden Queries verworfen. <br>
			Weiterzuleitende Nachrichten erhalten eine umso kleinere Priorität, desto mehr Hops(Servents) diese schon durchlaufen haben:
			Allerdings wird bei Query Hits genau entgegengesetzt der Strategie für weiterzuleitende Nachrichten vorgegangen, da sonst der vorangegangener Aufwand umsonst gewesen ist. <br>
			<br>
			Reihenfolge der Nachrichten nach Priorität:
			Push, Query Hit, Pong, Query, Ping
			<br>
			Individuelle Nachrichten werden im FC Modus bevorzugt.

Arnold at 15:44, 4 February 2006

2006-02-04T15:44:37Z

← Older revision		Revision as of 15:44, 4 February 2006
Line 4:		Line 4:
	*solange Queue < 25% ihrer max. Größe in Bytes, nichts weiter tun		*solange Queue < 25% ihrer max. Größe in Bytes, nichts weiter tun
	*ab 50%, Flow-Control-Modus benutzen		*ab 50%, Flow-Control-Modus benutzen
	*;solange bis wieder unter 25%		*:->solange bis wieder unter 25%
	*Größe der Queue sollte mindestens 150% der max. zulässigen Nachrichtengröße sein		*Größe der Queue sollte mindestens 150% der max. zulässigen Nachrichtengröße sein

Arnold at 15:41, 4 February 2006

2006-02-04T15:41:39Z

← Older revision		Revision as of 15:41, 4 February 2006
Line 1:		Line 1:
	Um Überlastungen eines Servents zu vermeiden wurde bei der neueren Version von Gnutella (~~v.0~~.6)		Um Überlastungen eines Servents zu vermeiden wurde bei der neueren Version von Gnutella (v0.6) ein Algorithmus zur Flow Control implementiert. <br>
			Der einfachste Ansatz wäre, die Verbindung zu schliessen, wenn zu viel Bandbreite beansprucht wird; besser ist es jedoch, weiterzuleitende Nachrichten zu verwerfen um der Traffic zu verringern. Somit würden aber auch Query Hits verworfen, wodurch vorangegangene Querys umsonst Traffic im Gnet verursacht hätten. <br>
			Daher wurde eine Outputqueue in Gnutella implementiert:
			*solange Queue < 25% ihrer max. Größe in Bytes, nichts weiter tun
			*ab 50%, Flow-Control-Modus benutzen
			*;solange bis wieder unter 25%
			*Größe der Queue sollte mindestens 150% der max. zulässigen Nachrichtengröße sein

Arnold at 15:30, 4 February 2006

2006-02-04T15:30:14Z

New page

Um Überlastungen eines Servents zu vermeiden wurde bei der neueren Version von Gnutella (v.0.6)