Port to .NET 5/6 #46
Replies: 13 comments
-
Entladen von Assemblies geht auch weiterhin mit .NET, dazu gibt es einen neuen Mechanismus ( Ein zweiter Prozess ist damit auch nicht trivial als Sandbox umzusetzen, ohne da plattformabhängige APIs zu nutzen (z.B. seccomp, namespace unter Linux). Der zweite Prozess kann ja per Default immer noch Dateien schreiben und Netzwerkverbindungen nutzen...
|
Beta Was this translation helpful? Give feedback.
-
Ich stelle mir die Frage ob es überhaupt den Aufwand wert ist den Ameisen Code von der Simulation zu isolieren. |
Beta Was this translation helpful? Give feedback.
-
Das war ja wohl ein Grund, und auch die Komplexität das zu portieren (insbesondere zu .NET Native...). Es gibt ja zwei verschiedene Probleme: Cheating über Netzwerk/IPC/o.ä. (nicht so wirklich schlimm) und ggf. Malware in gegnerischen Ameisenvölkern... Gegen Cheating im selben Prozess hilft ja schon ein einfacher anderer Prozess mit ein bisschen IPC-Code. Das hilft auch gegen Abstürze mit |
Beta Was this translation helpful? Give feedback.
-
Ja, den Aufwand zur Isolierung zu treiben ist essentiell. Sicher nicht für die eigene KI, aber spätestens im Multiplayer Modus und für eine Simulation online auf einem zentralen Server. Das ist einerseits Systemschutz, als auch Cheatsicherheit. Der Wegfall der CAS ist mir neu. das muss ich nachprüfen. Dieser Teil ist auch nicht mein primäres Problem. Viel problematischer ist der UI Kram. Der Mix aus klassischen Form Controls, 3D Rendering und dem plugin getriebenen Ansatz - und das Ganze Plattformübergreifend. Sehe keine perfekte Lösung 🙄 |
Beta Was this translation helpful? Give feedback.
-
CAS nicht mehr da 😱 damit wirds wirklich schwierig bzw. kompliziert. Damit braucht sowohl die Simulation, als auch die eigentliche Ameisenimplementierung einen eigenen Prozess - idealerweise sogar pro Ameise. aber es wird wohl pro Player werden... |
Beta Was this translation helpful? Give feedback.
-
Hier mal mein Senf zu CAS Alterantive im .net Aber wie wäre es, wenn man Plugins als "Self Contained Application" builden muss und dann nur einen bestimmten Teil an dlls erlaubt, aber System.IO, System.Net, etc. nicht. Die dlls würden dann nicht mit dem Plugin ausgeliefert werden, sondern mit der AntMe Version. So könnte dann AntMe die erlaubten dlls + plugin in einem seperaten Prozess starten. Wenn jemand System.IO nutzt oder System.Net, dann würde das Plugin bereits beim Laden den Fehler werfen, dass die dll nicht gefunden werden kann. Das einzige Problem, was ich mit diesem System sehe, sind verschiedene dll Versionen von den Framework dlls, aber hier könnten zumindest ansatzweise binding redirects Abhilfe schaffen, solange die genutzten Funktionen gleiche Signatur haben. Natürlich wäre es auch nicht mehr möglich, dass ein AntMe Plugin in mehrere dlls aufgetrennt werden kann, aber da ist die Frage, ob das überhaupt genutzt wurde oder bisher möglich war. Bezüglich UI: |
Beta Was this translation helpful? Give feedback.
-
Also, wie auf Twitter schon erwähnt, Unity als Engine wäre meine erste Wahl. 2D UI ist einfach und 3D bekommst du geschenkt. Außerdem ein Gameloop und jede Menge Game engine stuff. Als .Net kannst du zwischen 4.7 und .Net Standard aussuchen, wobei ich glaube 4.7 wird bald abgeschafft. |
Beta Was this translation helpful? Give feedback.
-
Der andere Punkt ist scheinbar das dynamische Laden von DLLs und geschriebenem Code. Da denke ich, wäre ein PlugInSystem denkbar, auch unter Unity, denn die Engine läuft separiert von allem, was ausgeführt wird. Ob eine Sandbox eingerichtet werden kann, weiß ich leider nicht. Aber wenn du den Unity Weg gehen würdest, könnte ich ja mal mit Kollegen von mir reden und/oder selber etwas versuchen. |
Beta Was this translation helpful? Give feedback.
-
Im Wesentlichen hat Sascha bereits meine Punkte genannt. CAS und die AppDomains stehen beide nicht mehr zur Verfügung. Die Begründung sind sehr vielschichtig. Die Portierung zu Linux stand im Weg, Performance und einige Runtime spezifischen API's die benötigt worden sind bereits deprecated gewesen. PluginsWie bereits erwähnt wären eigene Prozesse möglich (Netzwerk Kommunikation für Remote Extensions oder Sockets wenn auf dem gleichen Rechner). Wir haben damit bereits in unserem Bot experimentiert. Das hätte natürlich den Charm das AntMe! Selbst zwar in .NET geschrieben ist aber jede andere Sprache als Plugin möglich wäre. Es müsste nur eine Art Pluginhost geschrieben werden, der die Kommunikation übernimmt. Diese Flexibilität fänd ich schon cool und würde dem Teaching Charakter von AntMe! Entsprechen. Dll's direkt laden würde natürlich mit dem AssemblyLoadContext laufen. (Damit klappt nun auch entladen von dlls super) aber natürlich wäre auf diesem Weg das Thema Sicherheit nur deutlich oberflächlicher einsetzbar. UIAus meiner sehr bescheidenen Erfahrung heraus würde ich tatsächlich kein "klassisches" UI Framework verwenden, auch wenn das seine Anreize hätte. Die Möglichkeit auf ein Framework zu setzen das man einbinden kann und einem Arbeit abnimmt, wäre schon charmant. An sich gibt es unglaublich viele Frameworks da draußen, alle haben ihre Pro- und Contras. Da habe ich mit zu wenigen gearbeitet um eine gute Aussage treffen zu können Zum Thema großer komplett Pakete / Engine ala Unity und wie sie alle heißen würde ich selber nicht greifen. Ich glaube, das passt nicht mit der Philosophie zusammen die du mit AntMe! Vermittelst. Unity als Beispiel macht sicherlich "manche" dinge einfach und schön aussehende. Aber sehr viele Dinge lösen und erzwingen sie auf eine ganz eigene Weise. Da Programmieren vermittelt werden soll und nicht wie man mit Unity umgeht halte ich es nach wie vor Schwierig jemanden vor Unity zu setzen. Und die Engine ist auch für Anfänger meiner Meinung nach viel zu groß. Die Webvariante könnte eine interessante Möglichkeit darstellen, vor allem wenn man ganz Modern und Barriere los etwas als "as a Service" bereitstellen möchte (s.h. Codegame). Hier würde ich aber nur als Website selbst auf ein SPA Framework setzen. Der Kerninhalt würde ich mit einem JS Gameframework, umsetzen. Hier habe ich bei meinem Workshop mit Phaser eine gute Erfahrung gemacht. Da die Plugins auch Primär eher auf das Spiel selbst aus wären, wäre im Web damit das Pluginthema nicht ganz so wild wie mit einer Reinen Angular oder Vue etc... Lösung, da solche Frameworks sich durchaus leicht erweitern lassen würden. |
Beta Was this translation helpful? Give feedback.
-
Sehr coole Rückmeldung bisher. Ich danke euch. was die Code Sicherheit angeht ist das schon sehr nah an dem was ich ohnehin (auch für Lets code drones) konzipiert habe. Beim UI gehts ja in einige Richtungen. Die Unity Idee gefällt mir eigentlich ganz gut. Bei dem bisherigen Spiel gabs ein paar gute Argumente dagegen (Zu lange Startup Zeit, Deterministrik bei der Simulation, Unity lässt sich nicht in der eigenen Applikation hosten,...) die dagegen sprachen. Alles bedingt durch die Art und Weise wie der Spieler aktuell den Debugger startet (Exe wird bei jedem Debug Prozess neu gestartet). Ansonsten wäre der Web-Weg eine Alternative (wie bei drones geplant). nur dann vieles "zu fuß". Lasst uns dazu ein paar PoCs machen. Also sobald ich mal wieder am Rechner bin werde ich mal kurz skizzieren wie weit ich bei diesen Themen grundsätzlich bin und welche Eckdaten genau erfüllt sein müssen (und warum). |
Beta Was this translation helpful? Give feedback.
-
Hier mal ein paar pro/contra Argumente zu den Engines Unitypro
contra
Unrealpro
contra
|
Beta Was this translation helpful? Give feedback.
-
Da ich über Ostern aus Anreiz dieser Diskussion an dem alten 2017 Stand von AntMe! 2.0 gearbeitet hatte. Hatten Tom und ich eine kleine Konversation über das AppDomain Problem. Wie bereits hier vorausgehend erwähnt, gibt es die AppDomain und auch die CAS nicht mehr in net 6.0. Hier die kleine Zusammenfassung für euch und eure Ideen aus der Konversation Benötigt wird eine Mechanik wie CAS und AppDomain um vor Schadcode zu schützen (Ausführung von Code von Fremden) als auch das Cheat-problem im Multiplayer. Vor allem die Reflection ist in einem Wettkampfszenario ein Problem. AntMe! kann in der Cloud als auch auf einem lokalen Rechner laufen. Vor allem mit Reflaction lässt sich viel Unfug treiben. IPC Extensions sind cool was die Sprachunabhängigkeit angeht und sehr flexibel aber Interprozess Kommunikation ist sehr teuer und es kann nicht für jede Ameise ein eigener Prozess gestartet werden. Es soll verhindert werden das eine Ameise alles weiß. Eine Idee wäre gewesen den Code selber zu Parsen. Tom ist es jedoch wichtig nicht die IDE vorzuschreiben. Daher war unter anderem eine Idee den IL code einer Extension nach unerwünschten Implementierungen zu scannen. |
Beta Was this translation helpful? Give feedback.
-
Um CAS zu umgehen, gäbe es auch die Möglichkeit den source zu kompilieren und da direkt zu filtern. Es gab mal ein Wettbewerb welcher das so gemacht hat: https://github.com/SebLague/Chess-Challenge |
Beta Was this translation helpful? Give feedback.
-
Das hier ist ein dickeres Brett. Ich google mich gerade so durch. Soweit ich mich erinnere, hat @patteki damit schon angefangen und ist über eine Reihe von Problemen gestolpert die es zu lösen gilt.
Im Simulation Core Bereich gibts hier ganz klar das Sicherheitsproblem. Das aktuelle Spiel nutzt dafür AppDomains um a) den ausgeführten Code in seinen Zugriffsrechten stark zu limitieren (das würde grundsätzlich auch mit der Code Access Security (CAS) funktionieren. Aber sie sorgt auch für das saubere Entladen von externen DLLs nach der Simulation.
Um also eine klare Trennung zwischen Hauptapplikation und den Simulationsdaten zu schaffen, könnte man mit einem zweiten Prozess arbeiten. Soweit, sogut.
Auf UI Seite wird das Problem aber etwas umfangreicher. Wenn der Port auf .NET 5+ gleichzeitig die Plattformunabhängigkeit herbeiführen soll, muss sich das UI grundlegenden ändern. Aktuell ist das ja eine hübsche WinForms App deren Inhalte aus den geladenen Plugin-Libs mit weiteren WinForms UserControls gefüttert werden.
Um das mit einem passenden Konzept abzulösen fallen mir eine Reihe von Frameworks ein
Und jetzt stehe ich wieder da und weiß nicht weiter. Ich bitte um Diskussion
Beta Was this translation helpful? Give feedback.
All reactions