Flow Control

Flow Control Modus

Um Überlastungen eines Servents zu vermeiden wurde bei der neueren Version von Gnutella (v0.6) ein Algorithmus zur Flow Control implementiert.
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.
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

Im Flow Control Modus werden alle ankommenden Queries verworfen.
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.

Reihenfolge der Nachrichten nach Priorität:

Push, Query Hit, Pong, Query, Ping

Individuelle Nachrichten werden im FC Modus bevorzugt.

Solange die Outputqueue nicht zu 100% gefüllt ist, werden alle Nachrichten akzeptiert.
Erst wenn die Queue voll ist:

• Nachricht mit geringerer Priorität löschen (letzte in der Queue)
• ansonsten: Nachrichtentyp Query, Pong oder Ping verwerfen
• letzte Möglichkeit: Bye senden (Queue Überlauf)
  

zurück zum Index

Sachrifc

Sachrifc ist ein andere Ansatz um Überlastungen zu vermeiden; jedoch wurde dieser nicht in Gnutella implementiert. Die Ziele dieses Ansatzes sind:

• Verzögerung von Nachrichten zu minimieren
• Priorität der Nachrichten: Push, Query Hit, Query, Pong, Ping
• Verhindern, dass ein Nachrichtentyp den Verkehr dominiert
• Favorisierung von weniger populären Query Hits
  

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.
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.

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.
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