remote steuerung

Sovok

TheBigW schrieb:

Auch wann das eher nicht zu C++ gehört: Warum nicht DCOM, XML-RPC, Corba und Co.?
Ich hab bisher nur DCOM selber eigesetzt, weil man damit eine verteilte Anwendung richtig schön als ein großes ganzes basteln kann.

ich nehm mal an du hast die schon benutzt

welche vorraussetzungen müssen gegeben sein?
betriebssystem/os-features

die software läuft auch auf single threaded systemen mit sparsamen c++ support (keine exceptions/keine standard template library)

TGGC

Sovok schrieb:

muss ich noch irgendwas beachten bei memory operationen mit klassen ausser, dass das sizeof auf nen basisklassenpointer nicht die gesamtgrösse ergibt?

Wäre besser, keine virtuellen Methoden zu benutzen, sonst kommen 4(?) Byte dazu. 1 Byte Alignment kann auch sinnvoll sein.

Bye, TGGC (Denken, und gut ist.)

rüdiger

Sovok schrieb:

TheBigW schrieb:

Auch wann das eher nicht zu C++ gehört: Warum nicht DCOM, XML-RPC, Corba und Co.?
Ich hab bisher nur DCOM selber eigesetzt, weil man damit eine verteilte Anwendung richtig schön als ein großes ganzes basteln kann.

ich nehm mal an du hast die schon benutzt

welche vorraussetzungen müssen gegeben sein?
betriebssystem/os-features

die software läuft auch auf single threaded systemen mit sparsamen c++ support (keine exceptions/keine standard template library)

DCOM erwartet Windows und ist Microsoft spezifisch
*XML-RPC ist ein RPC Protokoll, dass XML zur Kommunikation nutzt *yuck Ist aber Plattform- und Sprach-unabhängig
*CORBA ist auch Plattform-/Sprach-unabhängig, aber bringt auch einiges an Komplexität mit (siehe ACE)

Sovok

1 Byte Alignment kann auch sinnvoll sein.

byte alignment kenn ich nur von structs... hoffe das funktioniert reibungslos mit klassen

Wäre besser, keine virtuellen Methoden zu benutzen, sonst kommen 4(?) Byte dazu

kommen ausser dem grösenunterschied noch weitere probleme mit virtuellen methoden hinzu?

was passiert wenn ich die virtuelle execute methode einbau, die instanz mit sizeof(abgeleitet) per socket verschick

dann auf der anderen seite den datenpointer in baseclass caste und execute aufrufe?

wird dann die implementierung der abgeleiteten aufgerufen oder stimmen nach dem transport die daten der instanz nicht mehr?

noch was anderes... wer kümmert sich um die anordnung der daten?
z.b. host(win32): little endian <-> client(linux): big endian

otze

noch was anderes... wer kümmert sich um die anordnung der daten?
z.b. host(win32): little endian <-> client(linux): big endian

der client kümmert sich drum

rüdiger

dann auf der anderen seite den datenpointer in baseclass caste und execute aufrufe?

Das funktioniert, wenn der Code auf beiden Seiten Binär kompatibel ist und die Implementation der Derived Klasse gleich zur Verfügung stehen (sind alles sehr schwierig einzuhaltende Bedingungen!), sollte alles gut gehen. Ansonsten hast du eben einen kaputten vtable und die daraus folgenden Erscheinungen.

Ich würde aber eher sagen, dass das nicht klappt.

Serialisiere einfach vernünftig und schicke keine Binärenklassen! Oder nimm ein existierendes RPC Protokoll (CORBA etc.)

sizeof auf einen Pointer liefert übrigens die größe des Pointer-Typs

noch was anderes... wer kümmert sich um die anordnung der daten?
z.b. host(win32): little endian <-> client(linux): big endian

*bumm* Deine Lösung wird so nicht gehen, wenn ich das sehe.

Aber zu der Frage. Wer sich darum kümmert: Niemand, darum muss sich dein Protokoll kümmern (bzw. dessen Implementierung)

Sovok

Serialisiere einfach vernünftig und schicke keine Binärenklassen!

was verstehts du unter vernünftig?

sizeof auf einen Pointer liefert übrigens die größe des Pointer-Typs

jaja natürlich sizeof((abgeleitet)pBase);

noch was anderes... wer kümmert sich um die anordnung der daten?
z.b. host(win32): little endian <-> client(linux): big endian

*bumm* Deine Lösung wird so nicht gehen, wenn ich das sehe.

Aber zu der Frage. Wer sich darum kümmert: Niemand, darum muss sich dein Protokoll kümmern (bzw. dessen Implementierung)

kümmern sich XML-RPC und CORBA um sowas?

TGGC

Sovok schrieb:

was verstehts du unter vernünftig?

Das eben nur der Befehlscode und die Parameter (am besten noch in definiertem Encoding) geschickt werden, statt einfach nur send( &class );

Bye, TGGC (Dem beste BdT)

Sovok

am besten noch in definiertem Encoding

wie ist ein definiertes Encoding richtig implementiert?

ansonsten würd ich halt nen buffer erstellen mit den ersten 4 bytes als id
und dann per template funktion die restlichen werte dranhängen

beim empfangen dann halt ein bischen pointerarithmetik a la

unsigned char* buffer;
m_lval1 = *(long*)buffer;
buffer += sizeof ( m_lval1 );
m_ival1 = *(int*)buffer;

...ach du sch*****
was mach ich dann wenn sich die grösse der datentypen ändert
z.b. long auf dem host 32bit und auf dem client 40bit

sollte ich die werte sämtlicher kommandoparameter per typedef auf ne bestimmte grösse setzen und dann die typedefs je nach plattform ändern?

ekelhaft is vorallem sowas

//32bit in 40bit variable schreiben
m_lval1 = *(long*)buffer;

//hab schon lang nich mehr geshiftet aber is des richtig?
m_lval1 = *(long*)buffer >> 8 ;

rüdiger

...ach du sch*****
was mach ich dann wenn sich die grösse der datentypen ändert
z.b. long auf dem host 32bit und auf dem client 40bit

sollte ich die werte sämtlicher kommandoparameter per typedef auf ne bestimmte grösse setzen und dann die typedefs je nach plattform ändern?

Ja, genau das sind die Probleme von Binär Sachen. Alignment kommt da wie bereits gesagt auch noch hinzu.

Schau dir am besten mal an, wie XML-RPC arbeitet. Du musst ja nicht unbedingt XML für das Protokoll nehmen.

TGGC

Sovok schrieb:

was mach ich dann wenn sich die grösse der datentypen ändert
z.b. long auf dem host 32bit und auf dem client 40bit

Genau sowas: man schickt nicht so, wie es grad im Speicehr steht. Wenn es mit allen mmöglichen Maschinen gehen soll, dann legst du fest, das die Übertragung z.b. big endian und int = 32 Bit sind. Jeder der sendet und empfängt muss dann evtl. konvertieren.

Bye, TGGC (Dem beste BdT)

Sovok

ok wie wärs mit

//CR == \r LF == \n

als DATATYPE gibts
32bit ganzzahl,
64bit fliesskomma,
8bit char,
unbestimmte länge string

reihenfolge little endian

beim schreiben müssen die datentypen in die jeweiligen längen gepresst werden und beim lesen darf nur die jeweilige länge gelesen werden

hab ich was übersehn?

was heisst eigentlich network byte order in der praxis...
hab das irgendwo aufgeschnappt

TGGC

Wenn die Strings nullterminiert sind, kannst du die LF streichen. Die ID sollte die Datentypen und deren Anzahl bestimmen, solange keine variablen Parameter (wie printf) nötig sind: Datatype und crlf streichen. Diese beiden Zeichen (cr/lf) können sowieso überall in den Daten auftreten.

Bye, TGGC (Dem beste BdT)

Sovok

TGGC schrieb:

Wenn die Strings nullterminiert sind, kannst du die LF streichen. Die ID sollte die Datentypen und deren Anzahl bestimmen, solange keine variablen Parameter (wie printf) nötig sind: Datatype und crlf streichen. Diese beiden Zeichen (cr/lf) können sowieso überall in den Daten auftreten.

Bye, TGGC (Dem beste BdT)

stimmt hast recht

also
<ID>(4byte)<DATA><DATA><DATA><DATA>...

wie siehts mit unicode strings aus
werden die auch mit \0 terminiert?

TheBigW

kümmern sich XML-RPC und CORBA um sowas?

Jep. Leider kann ich es nur für DCOM halbwegs erklären. Microsoft definiert einfach eigene Datentypen in der IDL, die dann je nach Zielsystem übersetzt werden. Das nimmt Dir somit die arbeit ab, Dich um sowas zu kümmern. Sonst würde es ja nie funktionieren den Server in C++ zu schreiben und die Clients dann mit z.B. VB einzubinden.
Im Prinzip arbeiten alle diese RPC Lösungen IMHO ähnlich. Der "Übersetzungsaufwand" zwischen den Systemen wird Dir suzusagen abgenommen. Ich glaube mich düster zu erinnern, das das irgendwie Marshalling, oder so ähnlich genannt wird.

Aber Dein Ansatz, sowas selbst zu basteln gefällt mir auch ganz gut .

Wenn ich mich recht entsinne sind unicode strings auch \0 terminiert.