Dezentrales Experimentiergrid

[Mareta Dagostino]

Vorab-Information

Ich plane ab Mitte September ein Testgrid aufzusetzen, wo ich Experimente zu einem dezentralen Grid starten möchte: Aufgeteilt in einen PHP-Gridserver, viele (also zwei) PHP-Inventar/Assetserver, und viele (zwei) Regionenserver. Die Regionenserver sollen sich dann beliebig ein (das) Grid aussuchen können. Die Residents wählen bei der Accounterstellung einen beliebigen (der beiden) Inventarserver.

Als Basis wird der Code von Freakys PHP-Gridserver dienen, und auf Regionenserverseite erst mal die Arriba. Weil Freaky bereits an einem Nachfolger programmiert, werde ich aber in die Arriba keinen Aufwand mehr stecken und vorerst in erster Linie mich mit dem Gridserver-Code beschäftigen. Mit Freaky hatte ich schon mal über meine Ideen gechattet, sie decken sich wohl in weiten Teilen mit seinen Ideen. So hoffe ich, dass aus diesem Experiment kein dauerhaft eigenständiger Fork wird, sondern ein "Steinbruch" möglicher Ideen.

Sowohl der geforkte Code als auch das Grid werden öffentlich erreichbar sein, sofern und soweit etwas lauffähig ist. Eine Besiedelung wie in Dereos oder OSgrid ist explizit nicht gewünscht! Es soll ein reines Experimentiergrid sein, wo jederzeit ohne Rücksprache alle Assets gelöscht werden können (keine Backups).

Erstmal werde ich das Projekt einfach privat und ohne Zeitdruck starten. Wer eventuell mitmachen möchte, darf sich natürlich gerne melden.

Liebe Grüße,
Mareta

[Bogus Curry]

Hallo Mareta ;D

Das hört sich gut an, bin gespannt was sich draus entwickelt. Würde mich sehr gerne dran beteiligen, in welcher Form auch immer ;D

[Gubbly]

Nette idee, Aber wo ist das den dezentral? In dem Moment wo ich einen Server aussuche ist es doch wieder zentral.

[Mareta Dagostino]

Du suchst Dir ein Grid aus, das verwaltet dann Deinen Account, Deine Gruppen usw. All die soziale Interaktion des Avatars läuft übers Grid, das ist die Community.

Wenn ein Grid groß wird, dann wächst der Assetserver ins Unermessliche und Hobbybetreiber stoßen früher oder später an technische Grenzen. Nur mit sehr großem administrativem Aufwand ist es zum Beispiel möglich Grids wie Metropolis oder OSgrid zu betreiben. Deshalb möchte ich die Inventare und Assets vom Grid trennen. Jeder kann dann zwar Resident im Grid sein, aber das Inventar entweder auf einem eigenen Server hosten oder einen Dienstleister in Anspruch nehmen. Als Rückfallebene kann natürlich auch das Grid selber einen oder mehrere Inventar-/Assetserver anbieten.

Ein Regionenbetrieber sucht sich das Grid aus (in Zukunft vielleicht mehrere Grids gleichzeitig?), wo die Region auf der Landkarte zugeordnet werden soll. Jeder Besucher bringt dann sozusagen den selbst gewählten Inventarserver Huckepack selber mit, wenn er was auf der Region rezzen will. Welchen Grids sich die einzelnen Besucher verbunden fühlen, ist der Region dann egal.

Soweit zur Vision... ;-)

[Mareta Dagostino]

Ja, so ähnlich. Ich würde da auch erstmal versuchen, die existierenden Hypergrid-Schnittstellen zu verwenden bzw. zu modifizieren. Was bisher fehlt, ist halt die Dezentralisierung der Assets/Inventare.

Wenn man einfach viele Standalones per Hypergrid zusammenschaltet, ist das zwar unglaublich dezentral, aber es fehlt die gemeinsame Community. Außerdem können viele Residents ihre Assets nicht sicher speichern und performant ans Web anbinden.

* Ein Resident sucht sich ein Grid und einen Asset-/Inventarserver aus.

* Ein Grid hat eine Community von Residents, verwaltet die eigene Landkarte, eigene Gruppen usw. Wenn sich ein Resident einen Account macht, gibt er den gewählten Assetserver an, das Grid merkt sich das.

* Eine Region bekommt wie beim Hypergid das Heimatgrid des Avatars mitgeteilt. Verschiedene Avatare aus dem selben Grid können aber auch verschiedene Assetserver haben.

* Der Assetserver ist eine dumpfe Datenbank, ohne irgendwem zugeordnet zu sein. Es können also theoretisch sogar Accounts verschiedener Grids den selben Assetserver benutzen, wobei die Idee natürlich gerade in Richtung vieler kleiner Assetserver zielt, statt in Richtung eines "Überservers".

Alles außer dem Grid kann dezentral betrieben werden, auch vom Resident selber. Wird auch das Grid dezentral betrieben, ist es faktisch eine aufgeblähte Standalone.

[Gubbly]

ähhh, das ist genau das Hypergrid. eine Region kann von mehreren Avataren besucht werden, und alle haben einen anderen Asset Server.

Das es in einem Grid mehrere Assets Server gibt, die unterschiedlichen Inhalt haben, ist vom Prinzip her nicht möglich.
Eine Region braucht einen festen Ansprechpartner um ihre Assets zu bekommen. Du kannst nicht einfach verlangen das die Region weiß auf welchen Server welches Asset liegt.
Und was passiert wenn der Server nicht verfügbar ist. Fehlt dann jedes 3e Object auf der Region?
Du kannst aber bereits die Assets auf mehrere Server spiegeln und die anfragen aufteilen. In beiden fällen hast du aber einen oder mehrere zentrale Server für ein ganzes Grid.

Du kannst aber bereits eine Standalone mit HG betreiben. Dann hast du im Grunde dein dezentral. Jede Region hat dann einen eigenen Asset und jeder Besucher hat sein eigenen Asset. Manche Besucher die aus großen Grids kommen, teilen sich den Asset dann zwar mit anderen, aber im großen und ganzen ist das doch genau das was du willst.
Dann fehlt nur ein Modul das eine globale Map bereitstellt.
Der Robust währe in diesem falle ein reiner Map Server. Dein ziel ist also gar nicht so weit entfernt. Braucht man nur ein Modul was sich in die Map einmischt. Alles andere gibt es schon.

[Bogus Curry]

Wie wäre es, wenn man das Inventar auf dem local pc vom Avatar auslagern würde ? Das könnte auch das backupen doch leichter machen, weil im Inventar ja meist immer mal selbstgebautes liegt. Ich denke mir das auch so, wenn man offline baut, das man dann sein Online-Inventar auch nutzen könnte.

Die Idee das eine Region in meheren Grids liegen könnte, das gefällt mir gut. So könnte man ein Projekt wie den Weltraumbahnhof besser verteilen, es gibt dann nicht nur ein Punkt zum teleporten sondern diese werden dann auf verschiedene Grids verteilt.

[Dorena Verne]

Ich muss Gubbly da zustimmen, so ganz weiß ich auch nicht wie du das jetzt genau vorhast, aber ich bin gespannt.

[Mareta Dagostino]

So könnte man ein Projekt wie den Weltraumbahnhof besser verteilen, es gibt dann nicht nur ein Punkt zum teleporten sondern diese werden dann auf verschiedene Grids verteilt.

Mit meinem Vorhaben möchte ich grundlegende Ideen ausprobieren für mögliche Lösungen in zukünftigen OpenSim-ähnlichen Grids. Es ist ein eher theoretischer Ansatz zum Auffinden und Beschreiben von Schnittstellen. Im Idealfall werden Lösungen gefunden, die in ein weiterentwickeltes OpenSim Einzug finden. Aber: Der Sourcecode in meinem Git wird immer experimentell sein und nie geeignet für "produktive" Grids.

... so ganz weiß ich auch nicht wie du das jetzt genau vorhast, aber ich bin gespannt.

Ich nenne mal die ersten Arbeitspakete:
- Auftrennen des PHP Gridservers in Grid und Asset
- Einrichten der Gits
- Aufsetzen von Doxygen
- Aufsetzen des Testgrids aus den aufgetrennten Einzelteilen (mit Avatarin Ruth)
- Schnittstellen suchen und dokumentieren
- Verknüpfungen planen, idealerweise (sparsam) mit UML dokumentiert
- neue Verknüpfungen implementieren
Etappenziel 1: Ein Grid, zwei frei wählbare Assetserver, zwei Regionenserver ohne sichtbare Nachbarregionen.

Weitere Aufgabenpakete für später:
- Nachbarschaftslogik (das wird ein großer Brocken)
- Logik zum automatisierten Löschen nicht mehr benötigter Assets (da sind schon Versuche gescheitert)
- ... tbd ...

[Mareta Dagostino]

Da der Danke-Button noch nicht funktioniert:

(Die Wahl des PHP-Gridservers fiel nicht zufällig, ich weiß dass ich es mir da einfach mache im Vergleich zu ROBUST. Gleich auch die grundsätzlichen Sicherheitsprobleme des Hypergrids erfolgreich anzugehen, wäre genial.)