Direct Service Requests/de

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(Created page with "{{Quicklinks|Direct_Service_Requests}} <br /> = Introduction = In the vast majority of cases, viewer requests are handled by the simulator which then interacts with backend s...")
 
(Konfiguration)
 
(11 intermediate revisions by one user not shown)
Line 1: Line 1:
 
{{Quicklinks|Direct_Service_Requests}}
 
{{Quicklinks|Direct_Service_Requests}}
 
<br />
 
<br />
= Introduction =
+
= Einführung =
  
In the vast majority of cases, viewer requests are handled by the simulator which then interacts with backend services (asset, inventory, etc.) as appropriate.
+
In der überwiegenden Mehrheit der Fälle werden Anfragen des Viewers vom Simulator bearbeitet, der dann entsprechend mit Backend-Diensten (Asset, Inventar, etc.) interagiert.
  
However, in the default configuration some of these requests are handled by the viewer interacting with a backend service directly. For instance, on login, the login service passes the viewer a [[map]] URL as configured in the MapTileURL section of [LoginService] in Robust.ini. When the viewer requires tiles to display on the main map, it contacts this URL to fetch them. The URL itself is served by the ROBUST service on the public grid port (8002 by default).
+
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.
  
There is also scope to handle more requests directly. However, the only good known working example, as detailed here, is one to handle GetTexture requests directly from a service rather than via a simulator. More examples will be added in the future, though with some there are currently some significant security considerations to bear in mind.
+
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.
  
= Direct GetTexture capability handling =
 
  
WARNING:  viewers may no longer use this
+
= Direkte Handhabung der GetTexture-Funktion =
  
 +
WARNUNG: Möglicherweise verwenden Viewer dies nicht mehr.
  
GetTexture is a client-viewer protocol [[capabilities|capability]] by which clients (viewers) can request textures via HTTP instead of the old UDP based mechanisms.
+
GetTexture ist ein Protokoll für die Client-Viewer-[[capabilities|Fähigkeit]], durch das Clients (Viewer) Texturen über HTTP anfordern können, anstelle der alten UDP-basierten Mechanismen.
  
Normally, OpenSimulator handles this by providing a capability endpoint that resolves to the simulator occuped by the user's avatar. Requests are received by the simulator and the asset retrieved from cache or by a call to the backend asset service as appropriate.
+
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.
  
However, we can also configure GetTexture to be handled directly by a service instead via the public grid port. The capability endpoint passed to the viewer then resolves directly to this service instead of the simulator, much like map tiles are provided directly by a service.
+
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.
  
This setup will work for both non-Hypergrid and Hypergrid installations (since all required assets are copied into the local asset service when a foreign user enters the simulator and when they rez or otherwise transfer items from their inventory).
+
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).
  
== Configuration ==
+
== Konfiguration ==
The first thing to do is to configure the service to provide the GetTexture capability connector. We can do this with the config below.
+
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.
  
 
<source lang="ini">
 
<source lang="ini">
Line 44: Line 44:
 
</source>
 
</source>
  
I'm assuming here that we are running the GetTexture service inside an entirely separate Robust service instance. However, it can be run in a Robust shell that it also handling other services (e.g. the default grid one that handles all services). In thie case, you can leave some sections out as we shall outline below.
+
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.
  
Here is an explanation of each section.
+
Hier eine Erklärung zu jedem Abschnitt:
  
* [Startup] - This is blank and only here to because the Robust service shell currently mandates it. It may not be necessary in the future. In a shared service shell an existing [Startup] section will be used.
+
* [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] - This triggers the initialization of the GetTexture capability connector. Here, we explicitly specify a port of 8010 though this can be omitted if it is the same as the default 'port' setting in the Network section. This is the port by which the viewer will be communicating with the GetTextureConnector so it must be accessible to a viewer through your firewall. You should not be running any private services (e.g. internal asset service) on this port.
+
* [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 will currently always complain if this is not present even if you only have one connector and that explicitly specifies the port you are using (as above). If you are expicitly specifying the GetTextureConnector port then this can be any free port on your server (it will not be used if there are no other services). If you are running GetTextureConnector in a shared service shell then any existing port setting will suffice.
+
* [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 - This specifies the asset service for GetTextureConnector to initialize from which to fetch textures (which are assets).
+
* [CapsService].AssetService – Dies gibt den Asset-Dienst an, den GetTextureConnector zur Initialisierung verwendet, um Texturen (die Assets sind) abzurufen.
* [DatabaseService] - This contains the settings for the AssetService to access the database. If GetTextureConnector is sharing the robust shell with other services then this very probably already exists.
+
* [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] - This section is blank and exists only to stop AssetService fatally complaining. It may disappear as a requirement in the future.
+
* [AssetService] – Dieser Abschnitt ist leer und dient nur dazu, zu verhindern, dass AssetService fatale Fehler meldet. In Zukunft könnte dies als Anforderung wegfallen.
  
Now, when you startup the Robust shell hosting GetTextureConnector and run the command "show http-handlers" you should see something like the following (for clarity we show the output where GetTextureConnector is the only thing running in the shell).
+
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>  
<pre>
+
R.O.B.U.S.T.# show http-handlers Registered HTTP Handlers for server at 0.0.0.0:8010  
R.O.B.U.S.T.# show http-handlers
+
* XMLRPC:  
Registered HTTP Handlers for server at 0.0.0.0:8010
+
* HTTP:  
* XMLRPC:
+
* HTTP (poll):  
* HTTP:
+
* JSONRPC:  
* HTTP (poll):
+
* LLSD:  
* JSONRPC:
+
* StreamHandlers (1): GET:/CAPS/GetTexture/  
* LLSD:
+
* StreamHandlers (1):
+
  GET:/CAPS/GetTexture/
+
 
</pre>
 
</pre>
  
This shows that the endpoint /CAPS/GetTexture is now available.
+
Dies zeigt, dass der Endpunkt /CAPS/GetTexture jetzt verfügbar ist.
  
Now we need to configure the simulators to provide viewers with the GetTexture capability that points to the service. In the [ClientStack.LindenCaps] section of OpenSim.ini for each simulator we need to add something like the following.
+
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">  
<source lang="ini">
+
[ClientStack.LindenCaps]  
[ClientStack.LindenCaps]
+
Cap_GetTexture = "http://192.168.1.2:8010/CAPS/GetTexture/"  
    Cap_GetTexture = "http://192.168.1.2:8010/CAPS/GetTexture/"
+
 
</source>
 
</source>
  
This overrides the usual "localhost" setting specified in bin/OpenSimDefaults.ini. In thie case, the URL points to a LAN IP (192.168.1.2). But for a public grid, this needs to be a public host that can be reached by all viewers (e.g. 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).
  
Now, when a viewer logs in it will make GetTexture requests directly to the service, by passing the simulator entirely. If the GetTextureConnnector is running in its own shell, you can check this is happening by running a command such as "show stats httpserver.8010.HttpRequestsServed.
+
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>  
<pre>
+
R.O.B.U.S.T.# show stats httpserver.8010.HTTPRequestsServed  
R.O.B.U.S.T.# show stats httpserver.8010.HTTPRequestsServed
+
httpserver.8010.HTTPRequestsServed : 139 requests, 0 requests/s, 0 requests/s  
httpserver.8010.HTTPRequestsServed : 139 requests, 0 requests/s, 0 requests/s
+
 
</pre>
 
</pre>
  
In this case, we can see that the service has now served 139 requests. Unfortunately, it's harder to check if the shell is being shared by multiple services on the same port - we do not currently register stats to show capabilities (though this should change in the future).
+
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).
  
=== Experimental configuration ===
+
=== Experimentelle Konfiguration ===  
'''This configuration is extremely experimental and not yet known to fully work. It's being left here for reference purposes.'''
+
'''Diese Konfiguration ist äußerst experimentell und noch nicht vollständig funktionsfähig. Sie wird hier zu Referenzzwecken belassen.'''
  
Instead of instantiating an AssetService to take care of GetTexture requests at the service end, we can potentially instantiate an HGAssetBroker instance when Hypergrid is active. At the moment, this is not necessary since assets are being copied into the local asset service when required (and so the vanilla GetTexture configuration above will always find them). However, there may be future experiments with not copying these assets up front and only requesting/caching them on demand. This will also require extra code to correctly transfer the asset if it is permanently required (e.g. because an attachment is rezzed in a region or given to another user).
+
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).
  
The configuration below is currently only possible in the 'ghosts' development branch in the OpenSimulator repository, as of commit 0437d44 (post 0.8), although this will soon be in master development code.
+
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.
  
The service side configuration for this is as follows. The simulator side configuration is the same as in the normal case.
+
Die Dienstkonfiguration dafür sieht wie folgt aus. Die Simulator-Seiten-Konfiguration ist dieselbe wie im Normalfall.
  
 
<source lang="ini">
 
<source lang="ini">
Line 122: Line 117:
 
</source>
 
</source>
  
The changes compared to the non-Hypergrid configuration are as follows.
+
Die Änderungen im Vergleich zur Nicht-Hypergrid-Konfiguration sind wie folgt:
  
* [CapsService].AssetService now instantiates HGAssetBroker from OpenSim.Region.CoreModules.dll rather than AssetService from OpenSim.Services.AssetService.
+
* [CapsService].AssetService instanziiert nun HGAssetBroker aus OpenSim.Region.CoreModules.dll anstelle von AssetService aus OpenSim.Services.AssetService.
* [AssetService] now contains two entries. The LocalGridAssetService entry tells HGAssetBroker which asset service to instantiate and use for home grid asset requests. The HypergridAssetService entry tells HGAssetBroker which asset service to instantiate and use for requests to foreign asset services.
+
* [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 is the entry required to get HGAssetBroker to run after it has been instantiated. This is necessary because up until very recently, HGAssetBroker was a region module only that was never instantiated by the CapsService. This requirement may go away in the future.
+
* [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.
  
= Pros and Cons =
+
= Vor- und Nachteile =
  
== Pros ==
+
== Vorteile ==  
Handling requests directly via a service has the following advantages.
+
Die Bearbeitung von Anfragen direkt über einen Dienst hat folgende Vorteile:
  
===Reduced simulator load===
+
=== Reduzierte Simulatorlast ===  
Handling requests directly by the service removes processing load from the simulator itself. This is most relevant to services that handle a high number of requests, such as GetTexture. However, the impact has not yet been properly measured.
+
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.
  
===Consistent performance===
+
=== Konstante Leistung ===  
When a request is handled directly by the service, performance in satisfying that request will not potentially vary between simulators operating under different conditions.
+
Wenn eine Anfrage direkt vom Dienst bearbeitet wird, wird die Leistung bei der Bearbeitung dieser Anfrage nicht durch unterschiedliche Bedingungen der Simulatoren beeinflusst.
  
== Cons ==
+
== Nachteile ==  
However, it also has the following disadvantages.
+
Es gibt jedoch auch folgende Nachteile:
  
===Textures local to regions do not work===
+
=== Regionen-lokale Texturen funktionieren nicht ===  
OSSL dynamic textures will not work, for example
+
Dynamische Texturen, die durch OSSL erstellt werden, funktionieren beispielsweise nicht.
  
===All load is on the service===
+
=== 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.
  
Instead of being spread to some extent between simulators, all service request load is now placed on the single service point (e.g. GetTexture).  This is particularly an issue in grids with higher numbers of users and simulators.  In the case of GetTexture and any request involving an asset, it's also the case that often these assets would be served from the local simulator cache.  However, this problem can be tackled by load balancing requests between multiple service instances, as all services are stateless.  Ultimately, one could also use alternative service implementations (e.g. SRAS for the asset service) which are likely considerably more efficient than the built-in ROBUST service implementations.  In general, a wealth of knowledge and software already exists for scaling services.
+
=== 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:
===Security===
+
<pre>  
 
+
OpenSim (test)# show caps list Region test:  
To take GetTexture as an example, if you run the command "show caps list" on the simulator when at least one user is logged in, you will see that the GetTexture capability is now served by a fixed URL rather than one which contains a random component. For example
+
** User f2f493c0-27d3-4cf2-be97-b44dfdad13b6:  
 
+
ObjectAdd /CAPS/OA/a7dd11fd-5f0c-4f5a-b70d-f558273101b5/  
<pre>
+
NewFileAgentInventory /CAPS/f608dd70-15f1-40a9-8780-8164c09627680002/  
OpenSim (test)# show caps list
+
FetchInventory2 /CAPS/176542be-6a06-4219-8647-cb57f8c9ec20  
Region test:
+
...  
** User f2f493c0-27d3-4cf2-be97-b44dfdad13b6:
+
GetTexture http://192.168.1.2:8010/CAPS/GetTexture/  
  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>
 
</pre>
  
This is because there is currently no mechanism for generating a random capability URL when a capability is being provided directly by a service. So in this case, for instance, anybody who knows the fixed GetTexture URL can request an asset if they know its ID.
+
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.
In the case of GetTexture, this is not considered a critical problem since there are many ways of fetching an arbitrary asset if the ID is known (though in cases of grids with restricted membership this might still be considered a problem). However, in other cases, such as the FetchInventory2 capability, this is a much more considerable problem. Ultimately, a mechanism for the simulator to register a random capability endpoint with the service hosting the capability will have to be implemented though this increases the complexity of the system.
+
 
+
===Some connectors cannot handle Hypergrid===
+
  
Currently, at least some capability connectors cannot operate in Hypergrid mode (though this isn't an issue with GetTexture). This situation will evolve in the future.
+
=== 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


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.

Personal tools
General
About This Wiki