TCP ist ganz nett gedacht, aber die Bedienung soll eigentlich nicht mit der Daten Komunikation verkuddelt werden.
Muss man doch auch nicht.
Das Datenprotokoll sollte vom Datentransport getrennt werden.
Prinzipiell gibt es zwei Arten von Datentransport:
* streambasiert (
TCP/
IP, Named Pipes,..)
* messagebasiert (UDP/
IP, Mailsots, Windows Messages,
SNMP, Dateidialog,...)
Bei einem Stream muss man selbst für die Trennung der einzelnen "Befehle" sorgen, während diese Aufgabe bei einem messagebasierten Datentransport schon erledigt ist.
Andererseits kann man mit vielen einzelnen Messages wieder einen Stream bilden.
Die beiden Transportarten können also ineinander umgewandelt werden.
Unabhängig vom Datentransport ist das Protokoll auf Anwendungsebene.
Man könnte z.B. das
POP3-Protokoll statt über
TCP/
IP auch über Named Pipes oder auch über Diskettenlaufwerke
(2 Rechner, jeder hat ein Diskettenlaufwerk und es gibt 1 Diskette. Der Benutzer muss die Diskette wechselseitig in Rechner A und B stecken) fahren.
Die grösste Fehler von
Indy ist dass Datentransport und Protokoll untrennbar miteinander verbunden sind.
Wenn man diesen Fehler vermeidet, dann kann es einem egal sein ob die Daten per
TCP/
IP, Named Piped oder was auch immer übertragen werden.
Das Protokoll könnte man z.B. auf
XML, JSON oder Canonical S-Expressions aufbauen.
Wenn es Allgemein sein soll, muss das Protokoll auf jeden Fall eine hierarchische Datendarstellung erlauben.
Eine Liste möglicher Protokolle gibt es hier:
http://en.wikipedia.org/wiki/Compari...zation_formats