Hallo, kennt jemand eine Möglichkeit, wie man in C# eine komplette Klasse, also inklusive ihren Methoden, in ein Byte Array o.ä. bekommt, sodass man sie dann wo anders wieder laden kann? Was ich erreichen möchte ist, dass ich einem Server sozusagen ein kleines Programm schicke, welches dann im Kontext des Servers ausgeführt werden soll. Ich glaub RPC ist so etwas ähnliches, nur soll das Programm in meinem Fall dauerhaft auf dem Server laufen, in einem eigenen Thread oder so. Oder gibt es einen anderen geläufigeren Weg dafür? MfG Mark
Mark .. schrieb: > Was ich erreichen möchte ist, dass ich einem Server sozusagen ein > kleines Programm schicke, welches dann im Kontext des Servers ausgeführt > werden soll. Und wieso verschickst Du denn nicht einfach das Programm?
Klar würde das gehen aber genau das Verschicken der kompletten Assembly wollte ich vermeiden. Gibt es eine Möglichkeit, einzelne Klassen zu extrahieren und nur diese zu verschicken? MfG Mark
du kannst bei c# glaube ich zur laufzeit code compilieren, du könntest alo den quelltext der classen übertragen.
Welche Art Virus willst Du denn verschicken? ;-) Das, was Dir vorschwebt, wirst Du in keiner Remote-Schnittstelle finden. Die einzige Möglichkeit, annähernd sowas zu machen, ist der Download (ggf. automatisch) und die vom Anwender zu bestätigende Installation Deines Software-Pakets. Gruß Markus
Was Peter sagt triffts ganz gut: Einfach den Quelltext rüberschicken (als Datei oder string) und den vor Ort kompilieren. Funktioniert wunderbar :-)
Wurz schrieb: > Was Peter sagt triffts ganz gut: > Einfach den Quelltext rüberschicken (als Datei oder string) und den vor > Ort kompilieren. > Funktioniert wunderbar :-) Wie soll das funktionieren?! Das würde nämlich erfordern, dass auf der Remote-Seite bereits eine SW läuft, die genau das leisten kann (Quellcode entgegennehmen, compilieren und die Assembly ausführen). Da kann man gleich die eigentliche Assembly installieren, mit der nichts mehr compiliert werden muss... Gruß Markus
Ja davin bin auch ausgegangen. Auf dem Server läuft ein Programm, welches Quellcode entgegennimmt und diesen zur Laufzeit compiliert und ausführt. Warum nicht? Markus Volz schrieb: > kann man gleich die eigentliche Assembly installieren, mit der nichts > mehr compiliert werden muss... Eher nicht. Es geht ja darum Quellcode dynamisch zur Laufzeit zu comilieren...
Wurz schrieb: > Eher nicht. Es geht ja darum Quellcode dynamisch zur Laufzeit zu > comilieren... Das ist Deine Interpretation. Der Ausgang war, wie man "eine komplette Klasse serialisieren" kann. Ein vorgeschlagener Lösungsweg war das Compilieren eines übertragenen Quellcodes. Ich möchte den Sicherheitsbeauftragten sehen, dem da nicht alle Haare zu Berge stehen. Gruß Markus
Markus Volz schrieb: > Welche Art Virus willst Du denn verschicken? ;-) > > Das, was Dir vorschwebt, wirst Du in keiner Remote-Schnittstelle finden. > Die einzige Möglichkeit, annähernd sowas zu machen, ist der Download > (ggf. automatisch) und die vom Anwender zu bestätigende Installation > Deines Software-Pakets. > > Gruß > Markus Java/BCEL/AspectJ/JSP u. Reflection, .NET/ASP.NET u. Reflection/CodeDom etc. sind für solche Sachen gedacht: Dynamische Codegenerierung zur Laufzeit.
Arc Net schrieb: > Java/BCEL/AspectJ/JSP u. Reflection, .NET/ASP.NET u. Reflection/CodeDom > etc. sind für solche Sachen gedacht: Dynamische Codegenerierung zur > Laufzeit. Ja und nein. Sinn und Zweck solcher Client-/Server-Schnittstellen ist es, dem Client bestimmte, möglichst eng umrissene serverseitige Funktionalität verfügbar zu machen. Alle (Programmierer-)Welt setzt Himmel und Hölle in Bewegung um Security-Leaks zu finden und zu stopfen. Niemand, der einigermaßen bei Verstand ist, wird einem Client eine Schnittstelle zur Verfügung stellen, bei der ALLES möglich ist, was dem Client auch nur irgendwie in den Sinn kommt. Aber ich will mich nicht weiter einmischen. Wenn jemand tatsächlich der Meinung ist, er brauche eine derartige Server-Schnittstelle, nur zu... :-) Gruß Markus P.S.: Ich halte (.NET) Reflection und Code-DOM durchaus für nützlich. ;-)
Man könnte ja spaßeshalber mal versuchen, verschiedenen Versionen des IIS solchen Sourcecode zu schicken. Wer weiß was die damit anfangen :-)
Hi an alle, also ich hätte wahrscheinlich noch erwähnen sollen, dass der Server ebenfalls von mir ist und somit prinzipiell alle möglichen implementierbaren Protokolle behandeln kann. Es ist auch kein normaler Webserver sondern eine Art Steuerungsprogramm, welches auf einem mobilen Roboter läuft und mit dem sich andere Programme per Netzwerk verbinden können, um die aktuellen Sensorwerte abzufragen oder die Aktoren anzusteuern. Im Moment ist es so, dass die meisten Programme, die den Roboter autonom irgendetwas machen lassen, ebenfalls auf dem Roboter laufen, da WLAN etwas Verzögerung hat, vorallem aber weil die auf dem Roboter montierte Kamera nur lokal ansprechbar ist. Nun möchte ich aber, dass die Programme alle auf meinem Rechner laufen. Damit die Kamera benutzbar und das ganze immer noch echtzeitfächig bleibt, sollen die Programme in zwei Teile aufgeteilt werden: Der "Hauptteil" läuft auf dem Rechner und bestimmt das eigentliche Verhalten des Roboters. Der andere Teil wird vor dem Start übers Netzwerk zum Server übertragen wird und dort im Kontext des Servers ausgeführt, wertet in Echtzeit die Bilder der Kamera aus und schickt die Ergebnisse zurück zum Rechner. Allerdings will ich nicht immer zwei Programme ("Hauptteil" und dem was auf dem Roboter läuft) für eine einzige Anwendung schreiben, sondern nur eins, welches sich dann quasi selbst aufsplitten und den Echtzeit-Teil auf dem Server ausführen soll. Meint ihr so etwas wäre machbar oder soll ich doch bei der rein lokalen Ausführung auf dem Roboter bleiben? MfG Mark
Mark .. schrieb: > Nun möchte ich aber, dass die Programme alle auf meinem Rechner laufen. Du willst also die Roboter von einem zentralen Rechner aus fernsteuern, ja? Dann mach das doch so. Die mobilen Clients (also die Roboter) senden Informationen (z.B. Daten ihrer Sensoren) an den Server, dieser verarbeitet die Daten und schickt Steuersignale (z.B. "vorwärts 1 Meter, drehe 90 Grad nach links") an die Clients. Warum man dafür Code transferieren sollte und nicht einfach Sensor-/Aktor-Daten, erschließt sich mir nicht so recht.
Also das Hauptproblem ist wie gesagt der Ping, also die Verzögerung. Bei mir besteht auch das Problem, dass die Verbindung mal für eine ganze Sekunde oder mehr stecken bleibt. In der Zeit kann eine Menge passieren, es sei denn man macht alle Bewegungen in Zeitlupe, was ich nicht möchte. Das andere Problem ist halt die Kamera, die ausschließlich lokal auf dem Roboter verfügbar ist. Die Bilder per Netzwerk verschicken kommt nicht in Frage, wiederum wegen der Verzögerung. Die Kamera selbst hat schon eine Verzögerung von ca. 1-2 Frames, wenn man das ganze dann auch noch komprimiert und über WLAN verschickt, wird man kaum unter 300ms kommen. MfG Mark
Mark .. schrieb: > kennt jemand eine Möglichkeit, wie man in C# eine komplette Klasse, also > inklusive ihren Methoden, in ein Byte Array o.ä. bekommt, sodass man sie > dann wo anders wieder laden kann? Wieso glaubst Du eigentlich, dass duch MEHR Daten über's Netz die Performance besser werden sollte? Mark .. schrieb: > Also das Hauptproblem ist wie gesagt der Ping, also die Verzögerung. Bei > mir besteht auch das Problem, dass die Verbindung mal für eine ganze > Sekunde oder mehr stecken bleibt. Vielleicht solltest Du mal suchen, wo das Problem eigentlich liegt? Ist vielleicht Dein "Server" der Verursacher, reagiert die Client-Hardware nicht schnell genug (CPU zu, Netzwerk ausgelastet,...). Bevor Du irgendwelch merkwürdige Konstrukte aufsetzt, die das Problem, von dem Du die Ursache nicht wirklich kennst, eher verschlimmern dürften, solltest Du mal nachforschen, was da eigentlich los ist. > > Das andere Problem ist halt die Kamera, die ausschließlich lokal auf dem > Roboter verfügbar ist. Die Bilder per Netzwerk verschicken kommt nicht > in Frage, wiederum wegen der Verzögerung. Die Kamera selbst hat schon > eine Verzögerung von ca. 1-2 Frames, wenn man das ganze dann auch noch > komprimiert und über WLAN verschickt, wird man kaum unter 300ms kommen. Andere bekommen Video-Livestreams über's Internet mit vergleichsweise geringer Bandbreite hin. Es mag vielleicht sein, dass Deine Roboter-Hardware überlastet ist, das WLAN ist mit hoher Wahrscheinlichkeit nicht das Problem. Gruß Markus
Markus Volz schrieb: > Wieso glaubst Du eigentlich, dass duch MEHR Daten über's Netz die > Performance besser werden sollte? Wie kommst du auf mehr Daten? Ich will ja eben weniger Daten verschicken, indem die Sensoren/Kamera lokal ausgewertet und nur die für genau dieses Programm relevanten Daten zum Hauptrechner geschickt werden. Markus Volz schrieb: > Vielleicht solltest Du mal suchen, wo das Problem eigentlich liegt? Ist > vielleicht Dein "Server" der Verursacher, reagiert die Client-Hardware > nicht schnell genug (CPU zu, Netzwerk ausgelastet,...). Bevor Du > irgendwelch merkwürdige Konstrukte aufsetzt, die das Problem, von dem Du > die Ursache nicht wirklich kennst, eher verschlimmern dürften, solltest > Du mal nachforschen, was da eigentlich los ist. So ist eben WLAN in einem Studentenwohnheim zwischen 10 anderen WLAN-Netzen... Klar könnte die Hardware auf dem Roboter schon besser sein, momentan ist es ein ARM9-Board mit 400MHz und ein simpler WLAN-Sick über USB. Nur habe ich halt momentan keine Lust, ein paar Hundert € für ein Netbook o.ä. auszugeben. Dafür aber genug Zeit und Lust, um auch mal neue Konzepte auszuprobieren. Es gibt Sachen, die man möglichst in Echtzeit machen sollte, wie, z.B. die Regelung der Motoren, damit sich die Räder gleichmäßig drehen, und das sollte auf dem Roboter laufen, während das Hauptprogramm das Verhalten bestimmt und auf einem stationären Rechner läuft. Einfach weil das Debugging dadurch einfacher wird. Markus Volz schrieb: > Andere bekommen Video-Livestreams über's Internet mit vergleichsweise > geringer Bandbreite hin. Es mag vielleicht sein, dass Deine > Roboter-Hardware überlastet ist, das WLAN ist mit hoher > Wahrscheinlichkeit nicht das Problem. Mit Bandbreite hat das ganze ja nichts zu tun, sondern mit der Verzögerung, die mir jetzt schon zu groß ist und durch Kompression und Senden, egal ob WLAN oder LAN oder was auch immer, nur größer werden kann. Eine andere Möglichkeit wäre es, ein analoge Funk-Kamera zu nehmen. Was die Übertragung selbst angeht, haben sie keine sichtbare Verzögerung, nur weiss ich nicht, wie schnell TV-Karten das ganze digitalisieren können. Wenn die Verzögerung minimal ist und das Bild nahezu in Echtzeit zur Verfügung steht, wäre es die ideale Lösung. Hat hier jemand zufällig eine und kann es mir verraten? MfG Mark
Mark .. schrieb: > kennt jemand eine Möglichkeit, wie man in C# eine komplette Klasse, also > inklusive ihren Methoden, in ein Byte Array o.ä. bekommt, sodass man sie > dann wo anders wieder laden kann? Mark .. schrieb: > Wie kommst du auf mehr Daten? Ich will ja eben weniger Daten > verschicken, indem die Sensoren/Kamera lokal ausgewertet und nur die für > genau dieses Programm relevanten Daten zum Hauptrechner geschickt > werden. Was denn nun? Bitte versteh mich nicht falsch, ich will Dich keinesfalls "auseinandernehmen", aber Deine Aussagen hier sind doch recht widersprüchlich. Aber vielleicht versteht ja jemand anderes Dich besser. :-) Gruß Markus
Nochmal zum Grundverständnis: Roboter: auf ihm läuft ein Programm, Code liegt üblicherweise im Flash PC-Server: auf ihm läuft ein Programm, der Code liegt z.B. auf der Festplatte und wird zur Laufzeit ins RAM geladen Zwischen den Robotern und dem Server: Daten flitzen hin und her, nicht Code, weder als Quelltext noch kompiliert Ist es nicht so? Wenn nein, warum soll es nicht so sein? Dass man Code zur Laufzeit auf ein Embedded System lädt, oder von einem Embedded System lädt, ist recht unüblich (es sei denn vielleicht es hätte keinen nichtflüchtigen Speicher? aber was für ein komisches System ist das ;-) Da muss es entweder einen guten Grund für geben, oder der Entwickler muss einsehen dass er sich geirrt hat. :-)
Also ich gebe zu, dass ich da selbst nicht ganz den Durchblick habe, wie das ganze am Ende genau aussehen soll, und bin prinzipiell auch für alle neuen Ideen und Vorschläge offen und dankbar. Hier mal eine kurze Zusammenfassung des aktuellen IST-Zustandes und dem, was mir daran nicht gefällt: Die Elektronik des Roboters besteht aus zwei Teilen, einem Motor/Servo-Controller auf AVR-Basis und dem Hauptboard, einem Mini2440 mit ARM9-Prozessor und Debian. Der Controller ist über UART ans Mini2440 angeschlossen. Damit mehrere Programme gleichzeitig die Sensoren des Roboters auslesen können, ohne einander zu behindern, läuft auf dem Roboter ein TCP/IP Server, mit dem sich andere Programme, sowohl vom Roboter aus als auch von einem anderen Rechner im Netzwerk, verbinden und die Sernsorwerte abfragen bzw. die Aktoren wie Motoren und Servos regeln können. Der Server ist also der einzige, der mit dem Motorcontroller direkt kommuniziert. Damit man die aktuellen Werte des Roboter immer unabhängig von anderen Programmen sehen kann, läuft auf meinem stationären Rechner ein Überwachungsprogramm, welches sich mit dem Server verbindet und die Sensorwerte grafisch anzeigt. Man kann damit den Roboter natürlich auch manuell steuern, wenn man es möchte. (Anwendungs-)Programme, die den Roboter autonom irgendetwas machen lassen, laufen dann lokal auf dem Roboter. Sie verbinden sich ebenfalls mit dem Server, lesen die Sensoren aus und teilen dem Server mit, welche Aktoren was machen sollen. Das ganze gleichzeitig während das Überwachungsprogramm ebenfalls mit dem Server verbunden ist. Meistens macht das Anwendungsprogramm aber natürlich nicht was es soll (bzw. nicht was ich will:)), und der spätere Erfolg hängt stark damit zusammen, wie gut man die Situation (also auch den physikalischen Zustand des Roboters), in der das Problem auftritt, eingrenzen kann und versteht, was genau der Roboter davor gemacht haben muss, damit er in diese Situation reinkommt. Hier reicht ein normaler Debugger einfach nicht mehr aus, da man als Mensch mit z.B. auf spezielle Weise visualisierten Daten mehr anfangen kann als mit bloßen Zahlen. Außerdem möchte man das Anwendungsprogramm manuell in einen bestimmten Zustand versetzen können, z.B. um eine bestimmte Situation immer und immer wieder durchlaufen zu lassen. Da das Programm aber auf dem Roboter läuft, kann man nicht einfach mal ein neues Fenster aufmachen und ein paar Buttons reinbauen. Man wird also für jedes Anwendungsprogramm eben noch ein seperates grafisches Frontend erstellen müssen, welches genau für dieses Programm gedacht ist und mit anderen nicht kompatibel ist. Da das Überwachungsprogramm aber schon sowieso mit dem Server verbunden ist und die Sensoren ausliest, liegt es natürlich nahe, dass man das Anwendungsprogramm einfach komplett auf dem Rechner als Modul des Überwachungsprogramms laufen lässt und das Frontend da direkt reinbaut. Was ich auch schon ausprobiert habe. Nur ist WLAN einfach nicht echtzeitfächig genug, meistens klappt es zwar aber in manchen Situationen merkt man schon den Unterschied zu einer direkt auf dem Roboter ausgeführten Anwendung. Deshalb sollen die Programmteile, die wirklich Echtzeitfächigkeit erfordern, auch direkt auf dem Roboter laufen. Ich will aber immer noch nur ein einziges Programm pro Anwendung schreiben. Daher auch die Idee, den Server so umzugestalten, dass er einfach Programmstücke per Netzwerk empfangen und in seinem Kontext ausführen kann. Im Programm auf dem Rechner erstelle ich dann eine Klasse, die ein bestimmtes Interface implementiert und dann vor der Programmausführung in den Roboter geladen wird. Dazu soll es möglich sein, manche Variablen quasi netzwerktransparent zu machen, so dass auf sie von beiden Seiten direkt zugreifen kann. Soetwas soll mit Attributes in C# möglich sein, wenn ich es richtig verstehe. Bleibt also noch die Frage, wie man denn nur eine einzelne Klasse zum Server überträgt. MfG Mark
Anders ausgedrückt, Du möchtest ein und das selbe Programm auf zwei verschiedenen Rechnern ausführen/aufteilen, die unterschiedliche Rechnerstrukturen (ARM9 - x86) haben.
Ja so ungefähr. Nur soll das Programm sich gewissermaßen selbst aufteilen. Btw mit verschiedenen Rechnerarchitekturen hat das primär nichts zu tun, da es ja sowieso in einer VM laufen würde. MfG Mark
Mark .. schrieb: > Ja so ungefähr. Nur soll das Programm sich gewissermaßen selbst > aufteilen. Btw mit verschiedenen Rechnerarchitekturen hat das primär > nichts zu tun, da es ja sowieso in einer VM laufen würde. Hm, wieso darf der gesamte benötigte Sourcecode nicht bereits für beide Prozessoren/Architekturen vorliegen? Vorkompiliert als Bytecode, damit er dann in der jeweiligen Virtual Machine ausgeführt wird? (ich nehme dabei mal an, dass sowohl auf dem Server als auch auf den Clients jeweils C# mit einer .NET Laufzeitumgebung eingesetzt wird) Im Moment verstehe ich nicht so recht die Notwendigkeit, warum zur Laufzeit entschieden werden soll, welcher Code wo läuft. Was ist der Grund dafür, dass man dies nicht im voraus entscheiden kann?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.