C++: Protokoll bei Client/Server Kommunikation

[Andre (Gast)]

Hallo,

ich bin dabei eine Client/Server Struktur in C++ aufsetzen.

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.

Meine Frage ist dazu: Welches Datenformat würde Ihr für die 
Kommunikation Vorschlagen?
Natürlich kann ich mir selbst was ausdenken und so ein Art 
"Chat-Struktur" aufbauen, in denen ich die verschickten Strings selbst 
auswerte. Aber gibt es dazu was Standardisiertes?

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


Danke,
Andre

[Rolf M. (rmagnus)]

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.

[D. I. (Gast)]

JSON, gibt Parser für jede gängige Sprache, ist kompakter als XML und 
auch gut lesbar. Solange du kein Showstopper hast der gegen JSON 
spricht, kann mans nehmen.

[Gerd E. (robberknight)]

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.

[res (Gast)]

Du solltest unbedingt beachten, wie groß die Wahrscheinlichkeit späterer 
Änderungen Deiner Request/Response-Strukturen ist. Kannst Du sicher 
sein, dass immer alle_ Client _zeitgleich mit dem Server aktualisiert 
werden können? Ansonsten muss Deine Serialisierung entsprechend flexibel 
mit unterschiedlichen Versionen umgehen können.

Ich habe für einen ähnlichen Anwendungsfall sehr gute Erfahrungen mit 
Googles "Protocol Buffers" gemacht. Es gibt aber eine Vielzahl ähnlicher 
Serialisierungslösungen.

[Eric B. (beric)]

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.

[Rolf M. (rmagnus)]

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 (Gast)]

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

Damit man das Protokoll einfach erweitern kann, sollten die Daten auch 
die Namen der Felder enthalten. Spricht für Json und XML. (Alte Server 
ignorieren die zusätzlichen Felder).

Es sollte mit beliebig strukturierte Daten funktionieren. Json und XML 
können zwar nur Baum-Strukturen, reicht aber eigentlich immer aus.

SOAP und CORBA sind wahnsinnig aufgebläht. Brauchst einiges an 
Einarbeitungszeit. Wenn es nicht verlangt wird, besser reines Json oder 
XML ohne den ganzen SOAP Verwaltungsoverhead.

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

Die Json-Parser sind kleiner als die XML-Parser. Ist aber nicht wirklich 
wichtig.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

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.

[The D. (thedaz)]

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.