Dezentrales Experimentiergrid

[Gubbly]

Woher bekommt man den den php Gridserver?
Ich hab zwar kein verlangen nach mehr Geschwindigkeit, aber zum Verständnis wie die Services funktionieren würde es mir helfen

[MoniTill]

- Logik zum automatisierten Löschen nicht mehr benötigter Assets (da sind schon Versuche gescheitert)

Mareta, ein mögliches Löschsystem wäre folgender Ablauf.

Man packt in die Asset-DB noch ein Zählerfeld für Verlinkung. Dieses belegt man mit einem Flag-Wert vor, zB -1 was heißt dieses Objekt wurde noch nicht angepackt. Anschließend bekommen alle Systemobjekte einen anderen Flag Wert -2, heißt, werden auch nie angepackt.
Dann muss jedesmal wenn ein Objekt neu angelegt wird ,dieses Feld eine 1 bekommen, für die erste Verlinkung zum Ersteller Inventar. Jedesmal wenn ein Objekt neu verlinkt wird und das Zählfeld einen positiven Ausgangswert hat, wird 1 dazu addiert. Wenn es irgendwo aus dem Inventar rausfliegt und das Feld einen positiven Wert hat, wird wieder einer abgezogen. Steht das Feld dann auf 0, ist das Objekt nirgendwo mehr im Einsatz und wird aus der DB gelöscht.
Das würde auf laufenden Grids schonmal eine Löschfunktion für alle neuen Objekte bedeuten. Die älteren bleiben davon unberührt.
Für diese müsste man ein Hilfsprogramm ähnlich dem Löschprogramm in SL bauen. Nur das dieses einmalig durchläuft.
Es greift sich sequentiell alle Objekte mit -1 raus und untersucht die ganze DB nach Verlinkungen. Ist die Anzahl am Ende >0 wird der Wert eingetragen, andernfalls das Objekt gelöscht.
Bei TB großen Datenbeständen ist das sicher eine längere Geschichte, aber wie gesagt nur einmalig nötig...

[MoniTill]

Freaky, das sagt mir jetzt so nichts.

Das war ein abstrakt theoretischer Ansatz wie sich das Problem grundsätzlich noch nachträglich lösen lässt, nachdem es anfangs laienhaft verschlampt wurde.
Die ganzen was wird wann wo abgelegt ist ein anderes Thema. Neben Hochladen/Erstellen gibt es das HG Mitbringsel. Oder wenn ich einen Würfel erstelle, ist er in der Regions-DB. Lösche ich ihn, ist er bei mir im Mülleimer und somit in der Asset-DB. Hole ich ihn wieder raus und lege ihn ab, bleibt er in der Asset-DB. Was ist mit OARs, wo landen die und und und. ..

[Christoph Balhaus]

Auch Scripte können Referenzen auf Assets enthalten. Diese kannst du aber mit Reference Counting kaum erfassen.

Beispiel: Ich habe eine Wand die eine Diashow zeigt. Die Textur wird mit llSetTexture(UUID, face) über deren UUID gesetzt und zyklisch und zufällig ausgetauscht. Die Liste der anzuzeigenden UUIDs (mehrere hundert) selber liegt in einer Notecard im Prim. Die Texturen müssen nicht mehr im Inventar existieren. Damit wäre der Link Count für diese Texturen dann 0 obwohl die Textur durchaus noch verwendet wird.

Um festzustellen welche Assets noch benötigt werden ist es also unerlässlich auch alle Scripte und Notecards nach UUIDs zu scannen - zumindest so lange man mit SL kompatibel bleiben will.

[MichelleArgus]

Um festzustellen welche Assets noch benötigt werden ist es also unerlässlich auch alle Scripte und Notecards nach UUIDs zu scannen - zumindest so lange man mit SL kompatibel bleiben will.

Theorethisch ja, aber die UUID könnte auch von ausserhalb des Grids übermittelt werden. Beispiel sind Vendoren die "ferngesteuert" werden und die Textur UUIDs von einem externen Webserver erhalten. Dies betrifft aber nur Texturen, Sound, Gesten u.ä., den rest (Objekte, Kleidung?...) könnte man in Scripts und Notecards scanen, also LM/Obkecte etc die in Scripts/Notecards gelistet werden, da diese nicht per Script aufgerufen werden können. ABER dank OSSL funktionen wiederum, ist es doch wieder möglich, z.B. NPC Klamotten anziehen ist auch per UUID, also wie beim Vendor und Textur nicht zwingend innerhalb des Grids erfassbar...

Wenn ich mich recht erinnere, hat SL den Ansatz gewählt, das Assets die nach x Jahre nicht mehr verwendet wurden, gelöscht werden, sofern die nicht irgendwo im Inventar gelistet werden. Wer also x Jahre nicht mehr online war, muss mit Inventarschwund rechnen, insbesondere Texturen. Assets von Maptexturen werden auf jeden fall regelmäßig in SL gelöscht, d.h. hier wird vermutlich zwischen dauerhaften und temporären Assets unterschieden. Man könnte auchin SL vermuten, das Assets die seit langen nicht mehr benötigt wurden, auf einen anderen Assetservice verschoben werden mit höherer Datenkomprimierung und geringerer Lesegeschwindigkeit und wenn diese Assets nicht mehr abgerufen werden, wird irgendwann gelöscht.

[Christoph Balhaus]

Theorethisch ja, aber die UUID könnte auch von ausserhalb des Grids übermittelt werden.

Ja das macht es ziemlich hoffnungslos mit Reference Counting die nicht mehr benutzten Assets zu erkennen und gleichzeitig kompatibel zu SL zu bleiben.

SL führt regelmässig Garbage Collections durch und sucht in den Inventaren, in den Objekten und scannt zusätzlich Scripte und Notecards bevor sie Assets löschen. Zusätzlich werten sie dann noch aus, ob das Asset eine bestimmte Zeit nicht mehr genutzt wurde. Letzteres würde dann einen Grossteil der von dir beschriebenen Fälle abdecken.

Kelly Linden hat die Prozedur vor vielen Jahren mal beschrieben, aber ich müsste jetzt erst intensiv suchen um das wiederzufinden. Zumindest habe ich in den letzten 8 Jahren dort keine Assets auf diese Weise verloren, obwohl viele nicht mehr im Inventar liegen.

Aber vielleicht ist es auch sinnvoll im Einzelfall von SL abzuweichen, wenn man dadurch an anderer Stelle gewinnen kann...

[Mareta Dagostino]

Instanzen von genutzten Assets verwalten ist nicht möglich, neben den oben erwähnten Aspekten crashen ja auch genügend Regionen. Die würden dann ihre genutzten Assets nicht abmelden, wenn der jeweilige Resident den Server danach mit einer neuen Region hochfährt. Und zumindest derzeit machen das viele so: Regionen absichtlich crashen, um Positionen auf der Map zu sichern. Wenn irgendwas im Server suspekt ist, neu installieren mit neuer Region, OAR einspielen und schon wäre der Zähler dauerhaft eins höher.

Derzeit hält ein Regionenserver nur Cache-Kopien der Assets und kann jederzeit die Assets vom Grid nachfordern, wenn er seine Kopien verliert. Dezentrale Assetserver in den Händen beliebiger Benutzer bedeuten aber auch, dass die Assetserver beliebig schlechte Qualität haben können, oft nur sporadisch im Web verfügbar sind, und vom Inventarbesitzer jederzeit ganz oder teilweise gelöscht werden können. Die Kopien auf dem Regionenserver werden also bei einer dezentralen Struktur sehr wichtig, will man längerfristig graue oder leere Flecken auf der Region vermeiden.

UUIDs in Scripten (die auf fremde Assetserver zeigen) können nicht mehr zuverlässig funktionieren, wenn Assetserver jederzeit verschwinden dürfen. Die Regionenserver benötigen nach der Dezentralisierung vollwertige Kopien aller Assets, die gerezzt sind oder von Scripten gerezzt werden könnten. Das Problem ist recht einfach zu lösen, wenn es den Scriptern bekannt ist: Man gibt die Assets in das Content-Verzeichnis zu dem Script ins gerezzte Objekt dazu.

[Gubbly]

Ich denke das ganze ist nur über Jahre hinweg möglich.
Ich denke man kann davon ausgehen das alle 6 Monate eine neue OpenSim Version erscheint.
Selbst wenn jemand nur jede 2e OpenSim Version benutzt kann man also sagen das eine Region Mindestens 1 Mal im Jahr seine Assets neu abruft.
Deswegen reicht es eigentlich wenn man die AccessTime in der AssetDB zum laufen bekommt.
Dann kann mann jedes Jahr hingehen und alle Assets die vor über einen Jahr das letzte mal abgerufen wurden und in keinem Inventar sind, löschen.
Das wollen die devs aber nicht. Warum nicht? Der kann sich das hier durchlesen.
http://opensimulator.org/mantis/view.php?id=7676

Und bevor da jetzt jemand schreit "Was ist den mit den Regionen die nicht updaten". Meiner Meinung können die vergammeln. Wer aktuell immer noch eine 076 benutzt verursacht mehr Probleme als sonst was.

[Bogus Curry]

@Gubbly: Das sind aber ziemlich viele, die eine ältere Version benutzen, da bin ich mir ziemlich sicher. Aus welchen Gründen auch immer, normal haben dann die Entwickler dafür sorge zu tragen, das die Version abwärtskompatibel sind oder sie sagen bitte auf eine bestimmte Version wechseln sonst habt ihr nachher nur noch Probleme.

Aber das ist ja nicht das Thema von diesem Thread ;D

[Mareta Dagostino]

Projektabbruch

Mitte September ist vorbei, deshalb fühle ich mich in der Pflicht hier noch abschließend was zu schreiben. Leider ist der Code von OpenSim doch arg unübersichtlich, so dass ich keine Idee gefunden habe die Schnittstellen zu kapseln. (Freaky hatte mich gewarnt, aber wenigstens gucken wollte ich mal. )

Was ich vielleicht hinbekäme, wären lauter dezentrale Einzelregionen ohne Nachbarn. Aber was will man damit, das gibt's schon unter dem Namen "Standalones". Der einzige Mehrwert wäre dann, dass sich mehrere Standalones einen gemeinsamen Inventarserver teilen können. Und das finde ich eine recht magere Ausbeute für den voraussichtlichen Aufwand.

In IM-Chats gab es zwar meist wohlwollende Kommentare, aber auch vornehme Zurückhaltung: Ich müsste das wohl alleine machen, und dafür wäre das Vorhaben zu groß. Gerade wo OpenSim derzeit im Umbruch ist mit drei ernsthaften Strömungen (Von Avination gepimpte Vanilla, White Core, Freakys Neuimplementierung), wird auch die Energie sicherlich anderswo dringender gebraucht.

Deshalb habe ich beschlossen, thematisch erst mal im Bereich Dokumentation und Konfiguration zu bleiben. Vielleicht gibt es ja demnächst Bedarf für White Core Konfigurationsanleitungen? Testen werde ich das jedenfalls, wenn die Hypergid-Anbindung kommt.

Liebe Grüße,
Mareta