Wie du ganz richtig erkannt hast ist das
Protokoll zwischen Client und Server der eigentliche Knackpunkt.
Der Datentransport über
TCP/
IP (oder Named Pipes, ser. Schnittstelle,...) ist da eigentlich eher nebensächlich.
Es gibt nun verschiedene Arten wie man diese Protokolle aufziehen kann.
Eine einfache Art wäre z.B. ein zeilenbasiertes Befehl- und Antwort Protokoll.
Ein gutes Beispiel dafür ist
SMTP,
POP3 oder
FTP.
Der Client schickt eine Textzeile (abgeschlossen mit CR-LF) als Befehl und der Server antwortet mit einem Status.
Sehr viele Internetprotokolle sind so aufgebaut.
Vorteile: einfach, kann mit einer Teminalemulation von Hand gut getestet werden
Nachteil: schlecht erweiterbar, unflexibel, nicht für komplexe Daten geeignet
Dann gibt es Protokolle, bei denen
XML als Grundlage benützt wird.
Alle Daten und Befehle werden als
XML verpackt und verschickt.
z.B.
XMPP und darauf aufbauend
Jabber.
Vorteile: beliebig erweiterbar, für komplexe, hierarchische Daten geeignet
Nachteile: aufwändig, benötigt hohe Netzbandbreite (ca. 95% der Daten sind "Luft")
man kann die
XML-Daten vor dem Senden auch komprimieren (zip) und damit den Netzbandbreite reduzieren
Eine sehr interessante Variante zu
XML ist
JSON.
Mit JSON kann man auch hierarchische Daten aufbauen ohne so weitscheifend wie
XML zu sein.
Dann gäbe es noch das
SDXF: Structured Data eXchange Format
mit dem man Daten binär und kompakt übertragen kann.
Der Nachteil von binären Protokollen ist aber, dass man nicht so einfach Debuggen kann.
PS:
das Schlechteste, was man tun kann ist
binäre Records zu übertragen.
Das ist zwar schnell programmiert, aber sehr unflexibel und schlecht zu portieren.
Verschiedene Programmversionen von Client und Server sind nach Änderungen an den Records nicht mehr kompatibel.
Ein gravierender Nachteil dabei ist auch, dass man Client und Server gleichzeitig entwickeln muss.
Bei allen textbasierten Protokollen kann man zuerst mit dem Server beginnen.
Der Server kann auch leicht mit einem Terminalprogramm getestet werden.