Ersatz für TSockets? - Experten gefragt!

[mcmichael]

Hallo Experten,

ich habe vor längerer Zeit schon einmal einen Anlauf genommen für ein Programm
TcpClient und TcpServer zu verwenden.
Es sollte im Prinzip eine gleichberechtigte Kommunikation (ähnlich einem chat)
zwischen den Rechnern/Programmen ablaufen.

Damals (zu Delphi 5-Zeiten) hatte ich solche Dinge über TClientSocket und TServerSocket
realisiert. Mit Delphi 2009 sind diese Komponenten raus. Man kann sie zwar wieder
einbauen (habe ich auch gemacht) aber mit den Strings haben sie so ihre Schwierigkeiten.

Also sollten TcpClient und TcpServer ran. Dort fehlten die Ereignisse um
auf empfangene Strings zu reagieren oder Methoden um vom Client zum Server
zu senden (das sei verpönt, wurde mir erläutert.)

Fehlanzeige ebenso mit den Indies. Teuren Support erkauft um im wesentlichen
die Wort zu hören "Das geht nicht. Sowas macht man ja auch nicht"
"Nur ein Server darf einen Client anrufen, umgekehrt ist Frevel"

Empfehlung: "TSockets verwenden"

Wirklich? Immer noch keine Alternative zu den Sockets verfügbar???
In allen möglichen Tutorials die ich zum Thema "chat" fand werden immer die Sockets
verwendet.

Wie schickt ihr Strings von Rechner a zu Rechner b und umgekehrt?
Und ich kann nicht glauben, daß man in einer Schleife in einem Thread
ständig nachfragen muß ob Daten da sind. Das muß doch ereignisgesteuert möglich sein...

any response appreciated!

McMichael

[BUG]

Evtl. ist SoNIC ja was für dich. Laut Beschreibung unterstützt es Events (bzw. Eine Callback-Prozedur) und hat ein Beispiel-Chatprogramm mitgeliefert.

MfG,
Bug

[mjustin]

Zitat:

Zitat von mcmichael

Wie schickt ihr Strings von Rechner a zu Rechner b und umgekehrt?
Und ich kann nicht glauben, daß man in einer Schleife in einem Thread
ständig nachfragen muß ob Daten da sind.

Das ist eigentlich keine Glaubensfrage, das ist schon fast ein Religionskrieg ;)

ICS und TClientSocket verwenden nichtblockierende Sockets, Indy und Synapse benutzen blockierende.

ICS (http://www.overbyte.be) wäre daher einen Blick wert.

Mit Threads (TIdThread zum Beispiel) arbeite ich aber lieber, da ich dabei genau steuern kann wieviele Bytes ich empfange. Mit ICS und ClientSocket erhält der Client immer einen ganzen Schwung Daten, aber zerhäckselt an irgendeiner Stelle, unvorhersehbar, Rest kommt halt später.

Cheers,

[SirThornberry]

wie mjustin bereits sagte ist das mehr als eine Glaubensfrage. Ich hab es mal mit den Indies versucht aber finde TServerSocket und TClientSocket einfach am besten. Wenn man sich um beide eine schöne Klasse mit entsprechendem Protokoll baut finde ich es unschlagbar.

[Apollonius]

Ich würde auch zu den alten Sockets raten. Du solltest aber tatsächlich auf SendTest und ReceiveText verzichten; das macht meistens sowieso nur Ärger. Mit SendBuf und ReceiveBuf kannst du ja genauso gut Strings versenden, nur musst du dir dort eben bewusst sein, ob es sich um Ansi- oder UTF-16-Daten handelt.

[samso]

Schau mal hier: http://www.overbyte.be

Diese Komponentensammlung arbeitet nicht in Thread-basierend (wie das die Indy-Server tun). Mit allen Vor- und Nachteilen, die das hat. Das man nichts vom Client zum Server schicken soll, habe ich ja noch nie gehört... Was mache ich in diesem Moment denn gerade?

[mcmichael]

Zitat:

Zitat von Apollonius

... Du solltest aber tatsächlich auf SendTest und ReceiveText verschicken; ...

damit ich das jetzt richtig verstehe: gemeint war möglicherweise
Du solltest aber tatsächlich auf SendText und ReceiveText verzichten.

oder?
wenn ja: warum denn?

[Apollonius]

Arg. Natürlich war "verzichten" gemeint, danke für den Hinweis.
SendText und ReceiveText verstecken die internen Zusammenhänge. Was mit einem Aufruf von SendText geschickt wird, muss nicht in einem Stück aus ReceiveText herauskommen. ReceiveText liefert den gesamten anstehenden Puffer als String; das kann Probleme machen, wenn sowohl Strings als auch Binärdaten verschickt werden. Viele Nutzer sind sich dieser Probleme nicht einmal ansatzweise bewusst. Ansonsten gibt es natürlich noch die Sache mit Unicode. Bei SendBuf und ReceiveBuf treten all diese Probleme nicht auf, insbesondere, weil die Länge der erwarteten Daten angegeben wird und dann auch genau diese Menge ausgelesen wird.

[mjustin]

Zitat:

Zitat von Apollonius

Bei SendBuf und ReceiveBuf treten all diese Probleme nicht auf, insbesondere, weil die Länge der erwarteten Daten angegeben wird und dann auch genau diese Menge ausgelesen wird.

Kann man auch bis zu einem bestimmten Begrenzer (Terminator) - Zeichen lesen?

Bei manchen Protokollen ist nicht im Voraus bekannt, wieviele Zeichen noch gelesen werden müssen, sondern bis zu einem z.B. Nullbyte.

Wenn das mit ReceiveBuf (oder einer anderen Funktion) nicht geht, hat man wieder das Problem, neben der Protokollbehandlung auch die zerbröselten Datenpaketen zusammenlöten zu müssen, was wieder etwas fummelig werden kann...

[Apollonius]

Windows unterstützt kein Lesen bis zu einem bestimmten Zeichen. Um das zu tun, sollte man wohl am besten einen anwendungsseitigen Puffer einrichten, der von Windows bei Bedarf Datenblöcke anfordert.