http://sourceforge.net/projects/indy10clieservr/
Das Problem ist nur, dass deine Demos nicht sauber trennen zwischen Datenaufbereitung (Protokoll) und Datentransport (
TCP/
IP).
Leider hat diesbezüglich
Indy selbst grosse Designfehler.
Nehmen wir z.B. die Klasse TIdSmtp als Umsetzung des
SMTP-Protokolls.
Gibt es aus Sicht von
SMTP einen Unterschied zwischen
TCP, Named Pipes oder Serieller Schnittstelle?
Antwort: Nein, sobald
TCP, Named Pipes oder ser. Port geöffnet sind verhalten sie sich gleich.
Man kann Daten lesen und Daten schreiben; es ist ganz einfach ein
bidirektionaler Stream.
Man hätte der Klasse TIdSmtp also über ein Property von Aussen diesen bidirektionaler Stream geben sollen.
Somit wäre es egal ob sich dahinter
TCP/
IP,
SCTP/IP oder sonstwas verbirgt.
Stattdessen hat man aber eine
sehr tiefe Klassenhierachie geschaffen:
Code:
TIdSmtp <- TIdSmtpBase <- TIdMessageClient <- TIdExplicitTLSClient <- TIdTCPClientCustom <- TIdTCPConnection <- TIdComponent <- TIdBaseComponent <- TIdInitializerComponent <- TIdNativComponent
Hier kann man als Analogie auch die Klassen TQuery, TDataSource und TDBGrid hernehmen.
Dem DBGrid ist es egal vorher die Daten kommen und wohin sie geschrieben werden.
Genau so hätte auch
Indy designed werden müssen (der kleine Nachteil ist, dass man so 3 statt nur einer Komponente braucht) .
Daher:
das Protokoll aus Anwendungsebene (OSI Level 7) muss unbedingt vom Datentransport getrennt gehalten werden!
Versuche doch einfach mal deine Demos so umzubauen, dass man sie wahlweise mit
Indy oder mit der
Unit ScktComp benützen kann (aber ohne Code zu duplizieren).