www.mikrocontroller.net

Forum: PC-Programmierung C# Klassendefinition "serialisieren"


Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom Ekman (tkon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DLL

Autor: mar IO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du kannst bei c# glaube ich zur laufzeit code compilieren, du könntest 
alo den quelltext der classen übertragen.

Autor: Markus Volz (valvestino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was Peter sagt triffts ganz gut:
Einfach den Quelltext rüberschicken (als Datei oder string) und den vor 
Ort kompilieren.
Funktioniert wunderbar :-)

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist schon ein sonderbarer Anwendungsfall ;-)

Autor: Markus Volz (valvestino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Markus Volz (valvestino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Volz (valvestino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. 
;-)

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man könnte ja spaßeshalber mal versuchen, verschiedenen Versionen des 
IIS solchen Sourcecode zu schicken. Wer weiß was die damit anfangen :-)

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Volz (valvestino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Volz (valvestino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mar IO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anders ausgedrückt, Du möchtest ein und das selbe Programm auf zwei 
verschiedenen Rechnern ausführen/aufteilen, die unterschiedliche 
Rechnerstrukturen (ARM9 - x86) haben.

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.