Monty Linden über die aktuelle Netzwerk-Architektur von SL

Quelle: SL Brand Center

Heute bin ich über den Blog von Nalates Urriah auf einen interessanten Thread im Second Life Forum aufmerksam geworden. Dort hat Monty Linden eine Grafik zur aktuellen Architektur des Datennetzwerks von Second Life veröffentlicht und einige Worte dazu geschrieben. Es ist zwar nicht viel, aber ein paar Infos für technisch interessierte SL-Nutzer sind trotzdem enthalten.

Der Thread hat die etwas abschreckende Überschrift meshmaxcon​currentreq​uests - does anybody know the real setting? und wurde von Jackson Redstar gestartet. Der wollte eigentlich nur wissen, warum es zur Viewer Debug Setting MeshMaxConcurrentRequests zwei fast identische Einträge gibt. Diese Einstellung dient dazu, dem Viewer vorzugeben, wie viele Meshes er gleichzeitig zum Download beim Server anfordern soll. Jackson stellte die Frage, weil er mit dieser Einstellung experimentiert, wenn bei seinem Job als Hochzeitsfotograf in SL mal wieder nur die Hälfte der Meshes bei einer größeren Gruppe von Avataren geladen werden.

Darauf gab es von Sara Carena erst einmal die Antwort, dass wohl MeshMaxConcurrentRequests gar nicht mehr aktiv ist. Es gibt jetzt eine neue Debug Setting mit dem Namen Mesh2MaxConcurrentRequests, die man verwenden sollte. Erkennbar an der "2" im Namen. Diese Einstellung ist auch schon in der SL-Wiki unter den Debug Settings aufgeführt.

Monty Linden hat diese Info von Sara Carena dann direkt bestätigt. Die alte Einstellung ist schon seit etwa einem Jahr inaktiv. Deshalb wurde nun auch ein "legacy" (veraltet) hinter den inaktiven Eintrag in der Wiki eingefügt.

Ausgelöst wird das Problem scheinbar durch eine Drosselung der Datenmenge aller Mesh-Attachments pro Avatar. Wird eine bestimmte Datenmenge überschritten, begrenzt irgendein Prozess den Download. Und das manchmal bis zum Stillstand. Was in so einem Fall Abhilfe schaffen soll ist, wenn der Avatar, bei dem nicht alle Meshes geladen werden, seine Inworld-Gruppe überm Kopf wechselt (oder überhaupt eine Gruppe aktiviert). Dadurch soll das Nachladen der noch fehlenden Daten vom Server angestoßen werden. Die Frage von Sara an Monty lautet nun, ob durch das neue Content Delivery Network (CDN) die Drosselung nicht aufgehoben wurde. Darauf antwortet Monty, dass die Begrenzung für den Mesh-Attachment Download immer noch besteht und nichts mit dem CDN zu tun hat. Vielmehr hängt das mit der Interest List und einigen intensiven Abläufen im Simulator zusammen.

Aktuelle Netzwerk-Architektur von SL

Dann geht Monty auf einen anderen Kommentar aus dem Thread ein, bei dem nach der aktuellen Netzwerk-Architektur von SL gefragt wurde und postet das hier eingebettete Diagramm. Dazu schreibt er dann die folgende Erklärung:

Das Diagramm zeigt links (in Rot eingerahmt) die Operationen im Viewer, rechts (in Blau eingerahmt) die Server/Simulatoren und unten in Grün den neuen CDN-Dienst. Die durchgezogenen Linien sind die Kommunikationswege zwischen Viewer, Server und CDN, sowohl unter HTTP als auch UDP. Die gestrichelten Linien zeigen veraltete Kommunikationswege, die bereits überflüssig wurden oder in Kürze noch werden.

Die schrägen Linien mit den Textbezeichnungen stellen Debug Settings dar und zeigen mit dem Kreis, auf welchen Kommunikationsweg sie sich auswirken. Auch hier sind die gestrichelten Linien wieder veraltete Debug Settings.

Generell gehen alle Änderungen in der jüngsten Zeit in die Richtung, die Kommunikationswege zu vereinfachen. Die Datenmenge für den HTTP-Download überwiegt inzwischen bei weitem die Menge, die noch über das alte UDP runtergeladen wird. Jedoch gibt es für das UDP keinen Drosselungsmechanismus, wie für das HTTP. Somit kann sich das UDP immer noch häufig das Vorrecht in den Kommunikationsverbindungen zwischen Viewer und Server erzwingen und verhindert ein ungestörtes Arbeiten des HTTP. Deshalb ist laut Monty hier die Einstellung der Bandbreite im Viewer immer noch sehr wichtig. Sie gilt nur für das UDP und verhindert ein "Überrennen" von HTTP. Monty erwähnt es zwar in seinem Posting nicht, aber nach meinem Wissen ist eine Einstellung von 1500 bis 2000 kbps immer noch die von LL empfohlene Bandbreite für die beste Verteilung zwischen UDP- und HTTP-Download. Viewer, die eine Bandbreite von 10.000 kbps eingestellt haben, bekommen eher Probleme mit Mesh-Download als mit kleineren Bandbreiten.

Zu den anderen Debug Settings sagt Monty dann nur, dass man sie lieber so lassen soll, wie sie im Viewer schon voreingestellt sind. Es gäbe in der SL-Community eine Menge falscher Ratschläge zu diesem Thema. LL arbeitet zur Zeit immer noch daran, die aktuelle Situation zu verbessern, indem man weitere optimierte HTTP-Verfahren ausprobiere.

Quelle: Monty Linden im SL-Forum