TIdTCP - Problem mit Read/Write

[stahli]

Indy ist m.E. (wenn ich nichts übersehe) eher ungeeignet für für einen Chat, da immer der Client Daten zum Server schickt und die Reaktion auswertet.
Mit Sockets ist die Kommunikation flexibler, da kann der Server gezielt bestimmte Clients von sich aus ansprechen.

[mjustin]

Zitat von stahli:

Indy ist m.E. (wenn ich nichts übersehe) eher ungeeignet für für einen Chat, da immer der Client Daten zum Server schickt und die Reaktion auswertet.
Mit Sockets ist die Kommunikation flexibler, da kann der Server gezielt bestimmte Clients von sich aus ansprechen.

Indy Socketverbindungen sind, wie alle TCP/IP Verbdindungen, auch bidirektional verwendbar. (kleine Verwechslungsgefahr: Sockets werden auch die Kanäle genannt, über die TCP/IP Daten ausgetauscht werden).

[ByTheTime]

Mein Problem war eben, das die Sockets alle in einem Hauptthread synchronisiert werden. Deswegen wollte ich auf Indy umsteigen, was ja praktisch einen echten Multithread Server bietet. Das kann ich ja mit den Sockets nicht realisiern, bzw. möchte keine eigene Klasse dafür schreiben.

[Bummi]

Du kannst es mit beidem realisieren.
Das synchronisieren findet bei den Indy's ja auch statt, es ist nur weggekapselt.

[ByTheTime]

Aber mit den Sockets ist es doch ein viel größerer Aufwand, oder nicht?

[stahli]

Ich hatte mit den Sockets Probleme beim Übertragen von Streams (kann aber natürlich an mir gelegen haben) und konnte das für meine Zwecke besser mit den Indys umsetzen.

Das darf man aber nicht verallgemeinern.

[Bummi]

@ByTheTime

Wenn Du bekannt Protokolle fahren willst, ja, hier bringen die Indy's schon (fast) alles mit.
Wenn Du ein eigenes Protokoll verwenden willst tust Du Dir mit den Sockets IMHO leichter.

[ByTheTime]

Ich übertrage im Moment auch Streams mit den Indys, weil es mit den Sockets nicht so super klappt. Aber für die Kommandos benutze ich nach wie vor die Sockets. Deshalb wäre es schön, das alles in eine Komponente zu packen.