Home

 

Download

 

News

 

Support

 

Admin

 

Dev

 

Screen Shots

 

Grid List

 

Bugs

Languages:

English    Deutsch    Français

Einführung

Dies sind Entwurfsnotizen zur Implementierung des LLUDP ClientStack in OpenSimulator, einem Code-Bereich, der dazu dient, Pakete von Viewern (Clients) zu senden und zu empfangen, die das Protokoll der virtuellen Umgebung von Linden Lab implementieren.

In diesem Sinne handhabt dieser Stack:

• Einrichtung eines eingehenden UDP-Handling-Stacks für jede Region.
• Verarbeitung eingehender UDP-Nachrichten von einem verbundenen Viewer.
• Verteilung empfangener UDP-Nachrichten an entsprechenden Verarbeitungscode (z. B. Auswahlverarbeitungscode, wenn ein Prim ausgewählt ist).
• Senden ausgehender UDP-Nachrichten an einen verbundenen Viewer.
• Drosselung ausgehender Nachrichten.
• Senden und Empfang von Ack-Nachrichten, sowohl inline in anderen Nachrichten als auch als eigenständige Nachrichten.
• Erneutes Senden von Nachrichten, die als zuverlässig markiert sind, aber für die der Empfang vom Viewer nicht bestätigt wurde.
• Drosselung ausgehender UDP-Nachrichten.
• Pooling von Clientstack-Strukturen (z. B. Klassen, die Nachrichten repräsentieren), um die Effizienz zu verbessern und den Speicherverbrauch zu reduzieren.

Nützliche Konsolenbefehle

Beachten Sie, dass diese Konsolenbefehle in OpenSimulator nicht mehr verfügbar sind. Die Beschreibung unten bleibt aus historischen Gründen an Ort und Stelle.

Dies sind Konsolenbefehle, die nützlich sind, um das LLUDP-Protokoll zu debuggen oder zu untersuchen.

• debug lludp packet [--default | --all] <level> [<avatar-vorname> <avatar-nachname>] - Aktiviert die Paketdebugging. In OpenSimulator 0.7.5 und früher lautete dieser Befehl "debug packet". "--default" wendet die neue Protokollierungsebene auf alle Avatare an, die sich nach diesem Zeitpunkt anmelden. "--all" wendet es auf alle vorhandenen Avatare an.
• debug lludp pool <an|aus> - Schaltet das Pooling von Objekten innerhalb des lludp-Komponente ein oder aus.
• debug lludp start <in|out|all> - Steuert die Verarbeitung von LLUDP-Paketen.
• debug lludp status - Gibt den Status der LLUDP-Paketverarbeitung zurück.
• debug lludp stop <in|out|all> - Stoppt die Verarbeitung von LLUDP-Paketen.

Eingehendes UDP

Code-Pfade

Teil 1

• Eingehende UDP-Nachrichten werden an einem Regionen-hörenden UDP-Port empfangen (derzeit in OpenSimUDPBase). Dabei handelt es sich um IOCP-Threads aus der Laufzeit, da die Verarbeitung asynchron erfolgt.
• Bei Empfang startet der Thread einen weiteren asynchronen Empfang (der möglicherweise von einem anderen IOCP-Thread verarbeitet wird).
• Jedes empfangene Paket wird auf Länge und grundlegende Fehlformen überprüft.
• Daten werden in eine Paketstruktur eingefügt, die aus einem Pool stammt.
• Wenn das Paket
  • UseCircuitCode ist (wird verwendet, um Schaltungen mit Viewern einzurichten), wird dies auf einem separaten Thread behandelt.
  • CompleteAgentMovement ist (wird verwendet, um die Einfügung eines Avatars in eine Region abzuschließen), wird dies auf einem separaten Thread behandelt.
  • Angehängte Bestätigungen zu einem normalen Paket enthält oder PacketAck ist, werden diese verarbeitet.
  • Zuverlässig ist, wird eine ausstehende Bestätigung in die Warteschlange gestellt, um dem Client eine Bestätigung zu senden.
  • AgentUpdate ist und nicht signifikant ist (wie das letzte Paket, bei dem diese etwa 10-mal pro Sekunde empfangen werden), wird es verworfen.
  • StartPingCheck ist, wird dies behandelt.
• Alle anderen Pakete werden in eine Warteschlange (packetInbox) für weitere Verarbeitung platziert.
• Der Thread wird freigegeben (synchroner Abruf derzeit nicht aktiv).

Teil 2

• Ein kontinuierlich laufender Thread ruft das nächste Paket am Anfang der packetInbox-Warteschlange ab.
• Es betritt die LLClientView-Struktur und protokolliert Details des Pakets zu Debugging-Zwecken, wenn erforderlich.
• Das Paket wird entweder synchron (auf diesem Thread) oder asynchron verarbeitet, indem es als Arbeitsauftrag in eine Warteschlange an einen Threadpool (standardmäßig SmartThreadPool) gestellt wird.
  • Einige Pakete werden synchron behandelt, weil Probleme auftreten können, wenn sie in falscher Reihenfolge verarbeitet werden (z. B. Änderungen von Mehrfach-Texturänderungen treten nicht richtig auf). Andere können standardmäßig synchron sein, wenn sie tatsächlich asynchron verarbeitet werden könnten.
• Der lang laufende Thread wiederholt sich.

Ausgehendes UDP

Code-Pfade

Dieser Abschnitt ist sehr unvollständig.

• LLUDPServer.SendPacketFinal() ist die vorletzte Methode, bevor UDP-Daten auf die Leitung gelegt werden.
  • Wenn das Paket nicht nullcodiert ist und Platz hat, werden eventuell wartende Bestätigungen angehängt.
  • Wenn das Paket zuverlässig ist, zeichnet der Server seine Erwartung an Bestätigungen vom Client auf.

• Wenn keine Pakete auf eine Drossel warten und keine im Ausgangsfach sind, wird BeginFireQueueEmpty() aufgerufen.

• LLUDPClient.BeingFireQueueEmpty löst das Ereignis HasUpdates aus, um festzustellen, ob Aktualisierungen anstehen.
  • LLClientView.HandleHasUpdates() behandelt dies und gibt true zurück, wenn es Entität-Updates, Entität-Eigenschafts-Updates oder Aktualisierungen des Bildmanagers (UDP-Asset-Download) in der Warteschlange hat.

• Wenn solche Updates anstehen, wird ein Threadpool FireQueueEmpty() Thread ausgelöst.
• Dies löst dann das OnQueueEmpty-Ereignis aus.
  • Das LLClientView behandelt dies mit HandleQueueEmpty(), das eine bestimmte Anzahl von Updates über OutPacket() platziert.

Drosseln

Es gibt auch eine alte informelle

Diskussion über Drosseln unter Sim Throttles, die möglicherweise genau oder ungenau sein kann.

Ausgehendes UDP wird pro Client mit optionaler Drossel für die gesamte Szene gedrosselt.

Einstellungen

Wenn

[ClientStack.LindenUDP]
enable_adaptive_throttles = true

(der aktuelle Standard) ist. Dann werden Client-Drosseln automatisch vom Server angepasst. Während die Verbindung in Ordnung ist, werden die Raten erhöht. Wenn jedoch Pakete, die als zuverlässig markiert sind, nicht rechtzeitig empfangen werden, wird die Drossel reduziert, bis keine Pakete mehr verloren gehen. Die Drossel wird dann allmählich wieder erhöht, bis entweder die vom Client angeforderte Drossel erreicht ist oder mehr Pakete verloren gehen.

Wenn

[ClientStack.LindenUDP]
enable_adaptive_throttles = false

Dann werden die Drosseln vom Client festgelegt.

Unabhängig von den adaptiven oder Client-Drossel-Einstellungen können Drosselraten auf der Serverseite durch Festlegen von

[ClientStack.LindenUDP]
client_throttle_max_bps = <some-client-limit>
scene_throttle_max_bps = <some-entire-scene-limit>

eingeschränkt werden. Die Einstellung client_throttle_max_bps setzt ein maximal Limit für jede Client-Verbindung durch. Die Einstellung scene_throttle_max_bps setzt ein maximales Ausgabelimit für alle Verbindungen zu einer Szene. Daher wird bei diesem letzten Limit die Bandbreite für alle durch jeden zusätzlichen Client geteilt, da ein festes Limit zwischen mehreren Clients geteilt wird. Dazu gehören auch Kind-Verbindungen (die für Clients mit Avataren in benachbarten Regionen verwendet werden, um Aktivitäten in dieser Region zu sehen).

Keines dieser Limits ist standardmäßig eingestellt.

Andere Verweise

• Sim Throttles enthält sehr alte Informationen zur Implementierung von Drosseln. Dies hat sich wahrscheinlich erheblich geändert, könnte aber immer noch nützlich sein.