Direct Service Requests/de
From OpenSimulator
(→Konfiguration) |
(→Konfiguration) |
||
| (9 intermediate revisions by one user not shown) | |||
| Line 8: | Line 8: | ||
Es besteht auch die Möglichkeit, weitere Anfragen direkt zu bearbeiten. Das einzige bekannte funktionierende Beispiel, wie hier beschrieben, ist jedoch die direkte Bearbeitung von GetTexture-Anfragen durch einen Dienst, anstatt über einen Simulator. Weitere Beispiele werden in Zukunft hinzugefügt, obwohl es bei einigen derzeit bedeutende Sicherheitsüberlegungen zu beachten gibt. | Es besteht auch die Möglichkeit, weitere Anfragen direkt zu bearbeiten. Das einzige bekannte funktionierende Beispiel, wie hier beschrieben, ist jedoch die direkte Bearbeitung von GetTexture-Anfragen durch einen Dienst, anstatt über einen Simulator. Weitere Beispiele werden in Zukunft hinzugefügt, obwohl es bei einigen derzeit bedeutende Sicherheitsüberlegungen zu beachten gibt. | ||
| + | |||
= Direkte Handhabung der GetTexture-Funktion = | = Direkte Handhabung der GetTexture-Funktion = | ||
| Line 55: | Line 56: | ||
Wenn Sie nun die Robust-Shell starten, die den GetTextureConnector hostet, und den Befehl „show http-handlers“ ausführen, sollten Sie etwas wie Folgendes sehen (zur Klarheit zeigen wir die Ausgabe, wenn nur GetTextureConnector in der Shell läuft). | Wenn Sie nun die Robust-Shell starten, die den GetTextureConnector hostet, und den Befehl „show http-handlers“ ausführen, sollten Sie etwas wie Folgendes sehen (zur Klarheit zeigen wir die Ausgabe, wenn nur GetTextureConnector in der Shell läuft). | ||
| − | <pre> R.O.B.U.S.T.# show http-handlers Registered HTTP Handlers for server at 0.0.0.0:8010 * XMLRPC: * HTTP: * HTTP (poll): * JSONRPC: * LLSD: * StreamHandlers (1): GET:/CAPS/GetTexture/ </pre> | + | <pre> |
| + | R.O.B.U.S.T.# show http-handlers Registered HTTP Handlers for server at 0.0.0.0:8010 | ||
| + | * XMLRPC: | ||
| + | * HTTP: | ||
| + | * HTTP (poll): | ||
| + | * JSONRPC: | ||
| + | * LLSD: | ||
| + | * StreamHandlers (1): GET:/CAPS/GetTexture/ | ||
| + | </pre> | ||
Dies zeigt, dass der Endpunkt /CAPS/GetTexture jetzt verfügbar ist. | Dies zeigt, dass der Endpunkt /CAPS/GetTexture jetzt verfügbar ist. | ||
Nun müssen wir die Simulatoren so konfigurieren, dass sie den Viewern die GetTexture-Fähigkeit zur Verfügung stellen, die auf den Dienst verweist. Im Abschnitt [ClientStack.LindenCaps] der OpenSim.ini für jeden Simulator müssen wir etwas Ähnliches hinzufügen: | Nun müssen wir die Simulatoren so konfigurieren, dass sie den Viewern die GetTexture-Fähigkeit zur Verfügung stellen, die auf den Dienst verweist. Im Abschnitt [ClientStack.LindenCaps] der OpenSim.ini für jeden Simulator müssen wir etwas Ähnliches hinzufügen: | ||
| − | <source lang="ini"> [ClientStack.LindenCaps] Cap_GetTexture = "http://192.168.1.2:8010/CAPS/GetTexture/" </source> | + | <source lang="ini"> |
| + | [ClientStack.LindenCaps] | ||
| + | Cap_GetTexture = "http://192.168.1.2:8010/CAPS/GetTexture/" | ||
| + | </source> | ||
Dies überschreibt die übliche „localhost“-Einstellung, die in bin/OpenSimDefaults.ini angegeben ist. In diesem Fall zeigt die URL auf eine LAN-IP (192.168.1.2). Für ein öffentliches Grid muss dies jedoch ein öffentlicher Host sein, der von allen Viewern erreicht werden kann (z. B. services.mygrid.com). | Dies überschreibt die übliche „localhost“-Einstellung, die in bin/OpenSimDefaults.ini angegeben ist. In diesem Fall zeigt die URL auf eine LAN-IP (192.168.1.2). Für ein öffentliches Grid muss dies jedoch ein öffentlicher Host sein, der von allen Viewern erreicht werden kann (z. B. services.mygrid.com). | ||
Wenn sich nun ein Viewer anmeldet, wird er GetTexture-Anfragen direkt an den Dienst senden und den Simulator vollständig umgehen. Wenn der GetTextureConnector in einer eigenen Shell läuft, können Sie überprüfen, ob dies der Fall ist, indem Sie einen Befehl wie „show stats httpserver.8010.HttpRequestsServed“ ausführen. | Wenn sich nun ein Viewer anmeldet, wird er GetTexture-Anfragen direkt an den Dienst senden und den Simulator vollständig umgehen. Wenn der GetTextureConnector in einer eigenen Shell läuft, können Sie überprüfen, ob dies der Fall ist, indem Sie einen Befehl wie „show stats httpserver.8010.HttpRequestsServed“ ausführen. | ||
| − | <pre> R.O.B.U.S.T.# show stats httpserver.8010.HTTPRequestsServed httpserver.8010.HTTPRequestsServed : 139 requests, 0 requests/s, 0 requests/s </pre> | + | <pre> |
| + | R.O.B.U.S.T.# show stats httpserver.8010.HTTPRequestsServed | ||
| + | httpserver.8010.HTTPRequestsServed : 139 requests, 0 requests/s, 0 requests/s | ||
| + | </pre> | ||
In diesem Fall sehen wir, dass der Dienst nun 139 Anfragen bearbeitet hat. Leider ist es schwieriger zu überprüfen, ob die Shell von mehreren Diensten auf demselben Port gemeinsam genutzt wird – derzeit registrieren wir keine Statistiken, um Fähigkeiten zu zeigen (dies sollte sich jedoch in Zukunft ändern). | In diesem Fall sehen wir, dass der Dienst nun 139 Anfragen bearbeitet hat. Leider ist es schwieriger zu überprüfen, ob die Shell von mehreren Diensten auf demselben Port gemeinsam genutzt wird – derzeit registrieren wir keine Statistiken, um Fähigkeiten zu zeigen (dies sollte sich jedoch in Zukunft ändern). | ||
| − | === Experimentelle Konfiguration === '''Diese Konfiguration ist äußerst experimentell und noch nicht vollständig funktionsfähig. Sie wird hier zu Referenzzwecken belassen.''' | + | === Experimentelle Konfiguration === |
| + | '''Diese Konfiguration ist äußerst experimentell und noch nicht vollständig funktionsfähig. Sie wird hier zu Referenzzwecken belassen.''' | ||
Anstelle der Instanziierung eines AssetService zur Bearbeitung von GetTexture-Anfragen am Dienstende können wir möglicherweise eine HGAssetBroker-Instanz instanziieren, wenn Hypergrid aktiv ist. Derzeit ist dies nicht notwendig, da die Assets bei Bedarf in den lokalen Asset-Dienst kopiert werden (und daher die oben beschriebene Standard-GetTexture-Konfiguration sie immer finden wird). Es könnte jedoch zukünftige Experimente geben, bei denen diese Assets nicht im Voraus kopiert, sondern nur bei Bedarf angefordert/zwischengespeichert werden. Dies erfordert auch zusätzlichen Code, um das Asset korrekt zu übertragen, falls es dauerhaft benötigt wird (z. B. weil ein Anhang in einer Region rezzt oder einem anderen Benutzer übergeben wird). | Anstelle der Instanziierung eines AssetService zur Bearbeitung von GetTexture-Anfragen am Dienstende können wir möglicherweise eine HGAssetBroker-Instanz instanziieren, wenn Hypergrid aktiv ist. Derzeit ist dies nicht notwendig, da die Assets bei Bedarf in den lokalen Asset-Dienst kopiert werden (und daher die oben beschriebene Standard-GetTexture-Konfiguration sie immer finden wird). Es könnte jedoch zukünftige Experimente geben, bei denen diese Assets nicht im Voraus kopiert, sondern nur bei Bedarf angefordert/zwischengespeichert werden. Dies erfordert auch zusätzlichen Code, um das Asset korrekt zu übertragen, falls es dauerhaft benötigt wird (z. B. weil ein Anhang in einer Region rezzt oder einem anderen Benutzer übergeben wird). | ||
| Line 103: | Line 119: | ||
Die Änderungen im Vergleich zur Nicht-Hypergrid-Konfiguration sind wie folgt: | Die Änderungen im Vergleich zur Nicht-Hypergrid-Konfiguration sind wie folgt: | ||
| − | + | * [CapsService].AssetService instanziiert nun HGAssetBroker aus OpenSim.Region.CoreModules.dll anstelle von AssetService aus OpenSim.Services.AssetService. | |
| − | + | * [AssetService] enthält jetzt zwei Einträge. Der Eintrag LocalGridAssetService teilt dem HGAssetBroker mit, welchen Asset-Dienst er für Anfragen des Home-Grids instanziieren und verwenden soll. Der Eintrag HypergridAssetService teilt dem HGAssetBroker mit, welchen Asset-Dienst er für Anfragen an externe Asset-Dienste instanziieren und verwenden soll. | |
| − | + | * [Modules].AssetServices ist der Eintrag, der erforderlich ist, um HGAssetBroker nach seiner Instanziierung auszuführen. Dies ist notwendig, da HGAssetBroker bis vor Kurzem nur ein Regionsmodul war, das niemals vom CapsService instanziiert wurde. Diese Anforderung könnte in Zukunft entfallen. | |
= Vor- und Nachteile = | = Vor- und Nachteile = | ||
| − | == Vorteile == Die Bearbeitung von Anfragen direkt über einen Dienst hat folgende Vorteile: | + | == Vorteile == |
| + | Die Bearbeitung von Anfragen direkt über einen Dienst hat folgende Vorteile: | ||
| − | === Reduzierte Simulatorlast === Die Bearbeitung von Anfragen direkt über den Dienst verringert die Verarbeitungslast des Simulators selbst. Dies ist besonders relevant für Dienste, die eine hohe Anzahl von Anfragen verarbeiten, wie z. B. GetTexture. Allerdings wurde die genaue Auswirkung noch nicht ausreichend gemessen. | + | === Reduzierte Simulatorlast === |
| + | Die Bearbeitung von Anfragen direkt über den Dienst verringert die Verarbeitungslast des Simulators selbst. Dies ist besonders relevant für Dienste, die eine hohe Anzahl von Anfragen verarbeiten, wie z. B. GetTexture. Allerdings wurde die genaue Auswirkung noch nicht ausreichend gemessen. | ||
| − | === Konstante Leistung === Wenn eine Anfrage direkt vom Dienst bearbeitet wird, wird die Leistung bei der Bearbeitung dieser Anfrage nicht durch unterschiedliche Bedingungen der Simulatoren beeinflusst. | + | === Konstante Leistung === |
| + | Wenn eine Anfrage direkt vom Dienst bearbeitet wird, wird die Leistung bei der Bearbeitung dieser Anfrage nicht durch unterschiedliche Bedingungen der Simulatoren beeinflusst. | ||
| − | == Nachteile == Es gibt jedoch auch folgende Nachteile: | + | == Nachteile == |
| + | Es gibt jedoch auch folgende Nachteile: | ||
| − | === Regionen-lokale Texturen funktionieren nicht === Dynamische Texturen, die durch OSSL erstellt werden, funktionieren beispielsweise nicht. | + | === Regionen-lokale Texturen funktionieren nicht === |
| + | Dynamische Texturen, die durch OSSL erstellt werden, funktionieren beispielsweise nicht. | ||
| − | === Die gesamte Last liegt auf dem Dienst === Anstatt die Last auf mehrere Simulatoren zu verteilen, wird die gesamte Last der Dienstanfragen jetzt auf den einzelnen Dienstpunkt (z. B. GetTexture) gelegt. Dies ist besonders in Grids mit einer höheren Anzahl von Benutzern und Simulatoren ein Problem. Bei GetTexture und jeder Anfrage, die ein Asset betrifft, ist es auch so, dass diese Assets oft aus dem lokalen Simulatorkachelspeicher bereitgestellt würden. Dieses Problem kann jedoch durch Lastverteilung auf mehrere Dienstinstanzen angegangen werden, da alle Dienste zustandslos sind. Letztlich könnten auch alternative Dienstimplementierungen (z. B. SRAS für den Asset-Dienst) verwendet werden, die wahrscheinlich deutlich effizienter als die eingebauten ROBUST-Dienstimplementierungen sind. Insgesamt gibt es bereits umfassende Kenntnisse und Software zur Skalierung von Diensten. | + | === Die gesamte Last liegt auf dem Dienst === |
| + | Anstatt die Last auf mehrere Simulatoren zu verteilen, wird die gesamte Last der Dienstanfragen jetzt auf den einzelnen Dienstpunkt (z. B. GetTexture) gelegt. Dies ist besonders in Grids mit einer höheren Anzahl von Benutzern und Simulatoren ein Problem. Bei GetTexture und jeder Anfrage, die ein Asset betrifft, ist es auch so, dass diese Assets oft aus dem lokalen Simulatorkachelspeicher bereitgestellt würden. Dieses Problem kann jedoch durch Lastverteilung auf mehrere Dienstinstanzen angegangen werden, da alle Dienste zustandslos sind. Letztlich könnten auch alternative Dienstimplementierungen (z. B. SRAS für den Asset-Dienst) verwendet werden, die wahrscheinlich deutlich effizienter als die eingebauten ROBUST-Dienstimplementierungen sind. Insgesamt gibt es bereits umfassende Kenntnisse und Software zur Skalierung von Diensten. | ||
| − | === Sicherheit === Am Beispiel von GetTexture: Wenn Sie den Befehl „show caps list“ auf dem Simulator ausführen, während mindestens ein Benutzer angemeldet ist, werden Sie sehen, dass die GetTexture-Fähigkeit nun über eine feste URL bereitgestellt wird, anstatt eine zufällige Komponente zu enthalten. Zum Beispiel: | + | === Sicherheit === |
| − | <pre> OpenSim (test)# show caps list Region test: ** User f2f493c0-27d3-4cf2-be97-b44dfdad13b6: ObjectAdd /CAPS/OA/a7dd11fd-5f0c-4f5a-b70d-f558273101b5/ NewFileAgentInventory /CAPS/f608dd70-15f1-40a9-8780-8164c09627680002/ FetchInventory2 /CAPS/176542be-6a06-4219-8647-cb57f8c9ec20 ... GetTexture http://192.168.1.2:8010/CAPS/GetTexture/ </pre> | + | Am Beispiel von GetTexture: Wenn Sie den Befehl „show caps list“ auf dem Simulator ausführen, während mindestens ein Benutzer angemeldet ist, werden Sie sehen, dass die GetTexture-Fähigkeit nun über eine feste URL bereitgestellt wird, anstatt eine zufällige Komponente zu enthalten. Zum Beispiel: |
| + | <pre> | ||
| + | OpenSim (test)# show caps list Region test: | ||
| + | ** User f2f493c0-27d3-4cf2-be97-b44dfdad13b6: | ||
| + | ObjectAdd /CAPS/OA/a7dd11fd-5f0c-4f5a-b70d-f558273101b5/ | ||
| + | NewFileAgentInventory /CAPS/f608dd70-15f1-40a9-8780-8164c09627680002/ | ||
| + | FetchInventory2 /CAPS/176542be-6a06-4219-8647-cb57f8c9ec20 | ||
| + | ... | ||
| + | GetTexture http://192.168.1.2:8010/CAPS/GetTexture/ | ||
| + | </pre> | ||
Dies liegt daran, dass es derzeit keinen Mechanismus zur Erstellung einer zufälligen Fähigkeit-URL gibt, wenn eine Fähigkeit direkt von einem Dienst bereitgestellt wird. In diesem Fall kann also beispielsweise jeder, der die feste GetTexture-URL kennt, ein Asset anfordern, wenn er dessen ID kennt. Im Fall von GetTexture wird dies nicht als kritisches Problem angesehen, da es viele Möglichkeiten gibt, ein beliebiges Asset abzurufen, wenn die ID bekannt ist (obwohl dies bei Grids mit eingeschränkter Mitgliedschaft möglicherweise als Problem betrachtet werden könnte). In anderen Fällen, wie der FetchInventory2-Fähigkeit, stellt dies jedoch ein viel größeres Problem dar. Letztlich muss ein Mechanismus implementiert werden, mit dem der Simulator einen zufälligen Fähigkeit-Endpunkt beim Dienst registriert, der die Fähigkeit hostet, obwohl dies die Komplexität des Systems erhöht. | Dies liegt daran, dass es derzeit keinen Mechanismus zur Erstellung einer zufälligen Fähigkeit-URL gibt, wenn eine Fähigkeit direkt von einem Dienst bereitgestellt wird. In diesem Fall kann also beispielsweise jeder, der die feste GetTexture-URL kennt, ein Asset anfordern, wenn er dessen ID kennt. Im Fall von GetTexture wird dies nicht als kritisches Problem angesehen, da es viele Möglichkeiten gibt, ein beliebiges Asset abzurufen, wenn die ID bekannt ist (obwohl dies bei Grids mit eingeschränkter Mitgliedschaft möglicherweise als Problem betrachtet werden könnte). In anderen Fällen, wie der FetchInventory2-Fähigkeit, stellt dies jedoch ein viel größeres Problem dar. Letztlich muss ein Mechanismus implementiert werden, mit dem der Simulator einen zufälligen Fähigkeit-Endpunkt beim Dienst registriert, der die Fähigkeit hostet, obwohl dies die Komplexität des Systems erhöht. | ||
| − | === Einige Konnektoren können Hypergrid nicht verarbeiten === Derzeit können mindestens einige Fähigkeits-Konnektoren im Hypergrid-Modus nicht betrieben werden (dies ist jedoch bei GetTexture kein Problem). Diese Situation wird sich in Zukunft weiterentwickeln. | + | === Einige Konnektoren können Hypergrid nicht verarbeiten === |
| + | Derzeit können mindestens einige Fähigkeits-Konnektoren im Hypergrid-Modus nicht betrieben werden (dies ist jedoch bei GetTexture kein Problem). Diese Situation wird sich in Zukunft weiterentwickeln. | ||
[[Category:German Translations]] | [[Category:German Translations]] | ||
Latest revision as of 05:12, 17 October 2024
 |
Languages: |
|
Contents |
[edit] Einführung
In der überwiegenden Mehrheit der Fälle werden Anfragen des Viewers vom Simulator bearbeitet, der dann entsprechend mit Backend-Diensten (Asset, Inventar, etc.) interagiert.
In der Standardkonfiguration werden jedoch einige dieser Anfragen vom Viewer direkt durch die Interaktion mit einem Backend-Dienst bearbeitet. Zum Beispiel übermittelt der Login-Dienst dem Viewer beim Anmelden eine map-URL, wie sie im Abschnitt MapTileURL von [LoginService] in der Robust.ini konfiguriert ist. Wenn der Viewer Kacheln benötigt, um die Hauptkarte anzuzeigen, kontaktiert er diese URL, um sie abzurufen. Die URL selbst wird vom ROBUST-Dienst über den öffentlichen Grid-Port (standardmäßig 8002) bereitgestellt.
Es besteht auch die Möglichkeit, weitere Anfragen direkt zu bearbeiten. Das einzige bekannte funktionierende Beispiel, wie hier beschrieben, ist jedoch die direkte Bearbeitung von GetTexture-Anfragen durch einen Dienst, anstatt über einen Simulator. Weitere Beispiele werden in Zukunft hinzugefügt, obwohl es bei einigen derzeit bedeutende Sicherheitsüberlegungen zu beachten gibt.
[edit] Direkte Handhabung der GetTexture-Funktion
WARNUNG: Möglicherweise verwenden Viewer dies nicht mehr.
GetTexture ist ein Protokoll für die Client-Viewer-Fähigkeit, durch das Clients (Viewer) Texturen über HTTP anfordern können, anstelle der alten UDP-basierten Mechanismen.
Normalerweise bearbeitet OpenSimulator dies, indem ein Endpunkt für die Fähigkeit bereitgestellt wird, der auf den vom Avatar des Benutzers belegten Simulator verweist. Anfragen werden vom Simulator empfangen, und das Asset wird aus dem Cache oder durch einen Aufruf des Backend-Asset-Dienstes abgerufen, je nachdem, was zutrifft.
Wir können jedoch auch konfigurieren, dass GetTexture direkt von einem Dienst über den öffentlichen Grid-Port bearbeitet wird. Der an den Viewer übermittelte Endpunkt verweist dann direkt auf diesen Dienst anstelle des Simulators, ähnlich wie Kartendaten direkt von einem Dienst bereitgestellt werden.
Diese Einrichtung funktioniert sowohl für Nicht-Hypergrid- als auch für Hypergrid-Installationen (da alle erforderlichen Assets in den lokalen Asset-Dienst kopiert werden, wenn ein externer Benutzer den Simulator betritt und wenn er Objekte aus seinem Inventar rezzt oder auf andere Weise überträgt).
[edit] Konfiguration
Als Erstes müssen wir den Dienst so konfigurieren, dass er den GetTexture-Fähigkeits-Connector bereitstellt. Dies können wir mit der folgenden Konfiguration tun.
[Startup] [ServiceList] GetTextureConnector = "8010/OpenSim.Capabilities.Handlers.dll:GetTextureServerConnector" [Network] port = 8010 [CapsService] AssetService = "OpenSim.Services.AssetService.dll:AssetService" [DatabaseService] StorageProvider = "OpenSim.Data.MySQL.dll" ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim;Password=mypassword;Old Guids=true;" [AssetService]
Ich gehe davon aus, dass wir den GetTexture-Dienst in einer vollständig separaten Robust-Instanz ausführen. Es ist jedoch auch möglich, ihn in einer Robust-Shell auszuführen, die auch andere Dienste verwaltet (z. B. der Standard-Grid-Dienst, der alle Dienste abwickelt). In diesem Fall können einige Abschnitte weggelassen werden, wie wir unten erläutern.
Hier eine Erklärung zu jedem Abschnitt:
- [Startup] – Dieser Abschnitt ist leer und nur vorhanden, weil die Robust-Service-Shell dies derzeit erfordert. Es könnte in Zukunft nicht mehr notwendig sein. In einer geteilten Service-Shell wird ein bereits vorhandener [Startup]-Abschnitt verwendet.
- [ServiceList] – Dies löst die Initialisierung des GetTexture-Fähigkeits-Konnektors aus. Hier spezifizieren wir explizit einen Port von 8010, obwohl dies weggelassen werden kann, wenn es derselbe wie die Standardeinstellung „port“ im Abschnitt Netzwerk ist. Dies ist der Port, über den der Viewer mit dem GetTextureConnector kommunizieren wird, daher muss er durch Ihre Firewall für den Viewer zugänglich sein. Sie sollten keine privaten Dienste (z. B. interne Asset-Dienste) auf diesem Port betreiben.
- [Network].port – OpenSimulator wird derzeit immer eine Fehlermeldung ausgeben, wenn dies nicht vorhanden ist, auch wenn Sie nur einen Konnektor haben und den von Ihnen verwendeten Port explizit angeben (wie oben). Wenn Sie den GetTextureConnector-Port explizit angeben, kann dies jeder freie Port auf Ihrem Server sein (er wird nicht verwendet, wenn es keine anderen Dienste gibt). Wenn Sie den GetTextureConnector in einer geteilten Service-Shell ausführen, reicht jede vorhandene Porteinstellung aus.
- [CapsService].AssetService – Dies gibt den Asset-Dienst an, den GetTextureConnector zur Initialisierung verwendet, um Texturen (die Assets sind) abzurufen.
- [DatabaseService] – Dies enthält die Einstellungen, damit der AssetService auf die Datenbank zugreifen kann. Wenn GetTextureConnector die Robust-Shell mit anderen Diensten teilt, existiert dieser Abschnitt sehr wahrscheinlich bereits.
- [AssetService] – Dieser Abschnitt ist leer und dient nur dazu, zu verhindern, dass AssetService fatale Fehler meldet. In Zukunft könnte dies als Anforderung wegfallen.
Wenn Sie nun die Robust-Shell starten, die den GetTextureConnector hostet, und den Befehl „show http-handlers“ ausführen, sollten Sie etwas wie Folgendes sehen (zur Klarheit zeigen wir die Ausgabe, wenn nur GetTextureConnector in der Shell läuft).
R.O.B.U.S.T.# show http-handlers Registered HTTP Handlers for server at 0.0.0.0:8010 * XMLRPC: * HTTP: * HTTP (poll): * JSONRPC: * LLSD: * StreamHandlers (1): GET:/CAPS/GetTexture/
Dies zeigt, dass der Endpunkt /CAPS/GetTexture jetzt verfügbar ist.
Nun müssen wir die Simulatoren so konfigurieren, dass sie den Viewern die GetTexture-Fähigkeit zur Verfügung stellen, die auf den Dienst verweist. Im Abschnitt [ClientStack.LindenCaps] der OpenSim.ini für jeden Simulator müssen wir etwas Ähnliches hinzufügen:
[ClientStack.LindenCaps] Cap_GetTexture = "http://192.168.1.2:8010/CAPS/GetTexture/"
Dies überschreibt die übliche „localhost“-Einstellung, die in bin/OpenSimDefaults.ini angegeben ist. In diesem Fall zeigt die URL auf eine LAN-IP (192.168.1.2). Für ein öffentliches Grid muss dies jedoch ein öffentlicher Host sein, der von allen Viewern erreicht werden kann (z. B. services.mygrid.com).
Wenn sich nun ein Viewer anmeldet, wird er GetTexture-Anfragen direkt an den Dienst senden und den Simulator vollständig umgehen. Wenn der GetTextureConnector in einer eigenen Shell läuft, können Sie überprüfen, ob dies der Fall ist, indem Sie einen Befehl wie „show stats httpserver.8010.HttpRequestsServed“ ausführen.
R.O.B.U.S.T.# show stats httpserver.8010.HTTPRequestsServed httpserver.8010.HTTPRequestsServed : 139 requests, 0 requests/s, 0 requests/s
In diesem Fall sehen wir, dass der Dienst nun 139 Anfragen bearbeitet hat. Leider ist es schwieriger zu überprüfen, ob die Shell von mehreren Diensten auf demselben Port gemeinsam genutzt wird – derzeit registrieren wir keine Statistiken, um Fähigkeiten zu zeigen (dies sollte sich jedoch in Zukunft ändern).
[edit] Experimentelle Konfiguration
Diese Konfiguration ist äußerst experimentell und noch nicht vollständig funktionsfähig. Sie wird hier zu Referenzzwecken belassen.
Anstelle der Instanziierung eines AssetService zur Bearbeitung von GetTexture-Anfragen am Dienstende können wir möglicherweise eine HGAssetBroker-Instanz instanziieren, wenn Hypergrid aktiv ist. Derzeit ist dies nicht notwendig, da die Assets bei Bedarf in den lokalen Asset-Dienst kopiert werden (und daher die oben beschriebene Standard-GetTexture-Konfiguration sie immer finden wird). Es könnte jedoch zukünftige Experimente geben, bei denen diese Assets nicht im Voraus kopiert, sondern nur bei Bedarf angefordert/zwischengespeichert werden. Dies erfordert auch zusätzlichen Code, um das Asset korrekt zu übertragen, falls es dauerhaft benötigt wird (z. B. weil ein Anhang in einer Region rezzt oder einem anderen Benutzer übergeben wird).
Die folgende Konfiguration ist derzeit nur im Entwicklungszweig 'ghosts' im OpenSimulator-Repository möglich, seit dem Commit 0437d44 (nach Version 0.8), obwohl dies bald im Hauptentwicklungszweig enthalten sein wird.
Die Dienstkonfiguration dafür sieht wie folgt aus. Die Simulator-Seiten-Konfiguration ist dieselbe wie im Normalfall.
[Startup] [ServiceList] GetTextureConnector = "8010/OpenSim.Capabilities.Handlers.dll:GetTextureServerConnector" [Network] port = 8010 [CapsService] AssetService = "OpenSim.Region.CoreModules.dll:HGAssetBroker" [DatabaseService] StorageProvider = "OpenSim.Data.MySQL.dll" ConnectionString = "Data Source=localhost;Database=opensimmaster2;User ID=root;Password=passw0rd;Old Guids=true;" [AssetService] LocalGridAssetService = "OpenSim.Services.AssetService.dll:AssetService" HypergridAssetService = "OpenSim.Services.Connectors.dll:HGAssetServiceConnector" [Modules] AssetServices = HGAssetBroker
Die Änderungen im Vergleich zur Nicht-Hypergrid-Konfiguration sind wie folgt:
- [CapsService].AssetService instanziiert nun HGAssetBroker aus OpenSim.Region.CoreModules.dll anstelle von AssetService aus OpenSim.Services.AssetService.
- [AssetService] enthält jetzt zwei Einträge. Der Eintrag LocalGridAssetService teilt dem HGAssetBroker mit, welchen Asset-Dienst er für Anfragen des Home-Grids instanziieren und verwenden soll. Der Eintrag HypergridAssetService teilt dem HGAssetBroker mit, welchen Asset-Dienst er für Anfragen an externe Asset-Dienste instanziieren und verwenden soll.
- [Modules].AssetServices ist der Eintrag, der erforderlich ist, um HGAssetBroker nach seiner Instanziierung auszuführen. Dies ist notwendig, da HGAssetBroker bis vor Kurzem nur ein Regionsmodul war, das niemals vom CapsService instanziiert wurde. Diese Anforderung könnte in Zukunft entfallen.
[edit] Vor- und Nachteile
[edit] Vorteile
Die Bearbeitung von Anfragen direkt über einen Dienst hat folgende Vorteile:
[edit] Reduzierte Simulatorlast
Die Bearbeitung von Anfragen direkt über den Dienst verringert die Verarbeitungslast des Simulators selbst. Dies ist besonders relevant für Dienste, die eine hohe Anzahl von Anfragen verarbeiten, wie z. B. GetTexture. Allerdings wurde die genaue Auswirkung noch nicht ausreichend gemessen.
[edit] Konstante Leistung
Wenn eine Anfrage direkt vom Dienst bearbeitet wird, wird die Leistung bei der Bearbeitung dieser Anfrage nicht durch unterschiedliche Bedingungen der Simulatoren beeinflusst.
[edit] Nachteile
Es gibt jedoch auch folgende Nachteile:
[edit] Regionen-lokale Texturen funktionieren nicht
Dynamische Texturen, die durch OSSL erstellt werden, funktionieren beispielsweise nicht.
[edit] Die gesamte Last liegt auf dem Dienst
Anstatt die Last auf mehrere Simulatoren zu verteilen, wird die gesamte Last der Dienstanfragen jetzt auf den einzelnen Dienstpunkt (z. B. GetTexture) gelegt. Dies ist besonders in Grids mit einer höheren Anzahl von Benutzern und Simulatoren ein Problem. Bei GetTexture und jeder Anfrage, die ein Asset betrifft, ist es auch so, dass diese Assets oft aus dem lokalen Simulatorkachelspeicher bereitgestellt würden. Dieses Problem kann jedoch durch Lastverteilung auf mehrere Dienstinstanzen angegangen werden, da alle Dienste zustandslos sind. Letztlich könnten auch alternative Dienstimplementierungen (z. B. SRAS für den Asset-Dienst) verwendet werden, die wahrscheinlich deutlich effizienter als die eingebauten ROBUST-Dienstimplementierungen sind. Insgesamt gibt es bereits umfassende Kenntnisse und Software zur Skalierung von Diensten.
[edit] Sicherheit
Am Beispiel von GetTexture: Wenn Sie den Befehl „show caps list“ auf dem Simulator ausführen, während mindestens ein Benutzer angemeldet ist, werden Sie sehen, dass die GetTexture-Fähigkeit nun über eine feste URL bereitgestellt wird, anstatt eine zufällige Komponente zu enthalten. Zum Beispiel:
OpenSim (test)# show caps list Region test: ** User f2f493c0-27d3-4cf2-be97-b44dfdad13b6: ObjectAdd /CAPS/OA/a7dd11fd-5f0c-4f5a-b70d-f558273101b5/ NewFileAgentInventory /CAPS/f608dd70-15f1-40a9-8780-8164c09627680002/ FetchInventory2 /CAPS/176542be-6a06-4219-8647-cb57f8c9ec20 ... GetTexture http://192.168.1.2:8010/CAPS/GetTexture/
Dies liegt daran, dass es derzeit keinen Mechanismus zur Erstellung einer zufälligen Fähigkeit-URL gibt, wenn eine Fähigkeit direkt von einem Dienst bereitgestellt wird. In diesem Fall kann also beispielsweise jeder, der die feste GetTexture-URL kennt, ein Asset anfordern, wenn er dessen ID kennt. Im Fall von GetTexture wird dies nicht als kritisches Problem angesehen, da es viele Möglichkeiten gibt, ein beliebiges Asset abzurufen, wenn die ID bekannt ist (obwohl dies bei Grids mit eingeschränkter Mitgliedschaft möglicherweise als Problem betrachtet werden könnte). In anderen Fällen, wie der FetchInventory2-Fähigkeit, stellt dies jedoch ein viel größeres Problem dar. Letztlich muss ein Mechanismus implementiert werden, mit dem der Simulator einen zufälligen Fähigkeit-Endpunkt beim Dienst registriert, der die Fähigkeit hostet, obwohl dies die Komplexität des Systems erhöht.
[edit] Einige Konnektoren können Hypergrid nicht verarbeiten
Derzeit können mindestens einige Fähigkeits-Konnektoren im Hypergrid-Modus nicht betrieben werden (dies ist jedoch bei GetTexture kein Problem). Diese Situation wird sich in Zukunft weiterentwickeln.
