C++: Protokoll bei Client/Server Kommunikation

Andre schrieb:
> 1. Client fragt beim Server nach einer bestimmten Information mit einem
> bestimmten Kommando.
> 2. Der Server führt das Kommando (Funktionsaufruf) aus und schickt die
> Antwort an den Client zurück.
> 3. Der Client kann mit der Rückantwort weiterarbeiten.

Man spricht dabei in der Regel von einem RPC-Mechanismus (Remote 
Procedure Call).


Andre schrieb:
> JSON ist so ein Datenformat, doch das wird eher bei Webanwendungen
> verwendet (laut Wiki).

Inwiefern disqualifiziert es das für deine Anwendung?
Ansonsten gibt's noch so Dinge wie SOAP oder CORBA (wenn das heut noch 
verwendet wird). Das geht dann über ein reines grundlegendes Datenformat 
schon deutlich hinaus.

json ist gut wenn das ganze auch mal von Menschen gelesen werden soll.

wenn es aber auf Performance ankommt dann schau mal nach zeromq. dafür 
gibt es seit kurzem auch noch einen rpc-aufsatz, das macht dann nicht 
nur das encoding und transfer, sondern auch das handling des aufrufs.

Andre schrieb:
> Der Ablauf ist ca. wie folgt:
> 1. Client fragt beim Server nach einer bestimmten Information mit einem
> bestimmten Kommando.
> 2. Der Server führt das Kommando (Funktionsaufruf) aus und schickt die
> Antwort an den Client zurück.
> 3. Der Client kann mit der Rückantwort weiterarbeiten.

Das hat alles mit C++ aber ziemlich wenig am Hut. Oder ist das Kommando 
tatsächlich ein C++ Funktionsaufruf?

> Meine Frage ist dazu: Welches Datenformat würde Ihr für die
> Kommunikation Vorschlagen?

Das Format das für deine Anwendung am besten passt. Oben auf dein 
Datenformat kommt dann noch ein Protokoll

> Man spricht dabei in der Regel von einem RPC-Mechanismus (Remote
> Procedure Call).

Aber nur wenn Client und Server tatsächlich "remote" mit einander 
kommunizieren müssen. Das hat der TO aber nicht erwähnt.

Eric B. schrieb:
>> Man spricht dabei in der Regel von einem RPC-Mechanismus (Remote
>> Procedure Call).
>
> Aber nur wenn Client und Server tatsächlich "remote" mit einander
> kommunizieren müssen. Das hat der TO aber nicht erwähnt.

Das ist zumindest das, was ich unter Client/Server verstehe.
Ohne "remote" bleibt von dem ganzen ja nur ein simpler Funktionsaufruf 
übrig.

Noch einer schrieb:
> Es ist recht praktisch, wenn man zum Debuggen ein telnet oder netcat
> benutzen kann. Damit scheiden alle Binärformate aus.

So schlimm ist es auch nicht. Für Standard-Binärformate: Wireshark 
regelt das.

Noch einer schrieb:
>
> SOAP und CORBA sind wahnsinnig aufgebläht.

Im Vergleich zu XML ist Corba kompakt weil die Daten eben binär 
übertragen werden.

>
> Tools, die Code zum Serialisieren der C++Klassen generieren, lohnen sich
> meist nicht.

Sehe ich anders. Für eine einzige Methode ist das wohl ein zu großer 
Hammer. Aber wenn wir von dutzenden Interfaces mit komplexen Datentypen 
sprechen ändert sich die Sache.