TIdTCP - Problem mit Read/Write

[ByTheTime]

Hallo,
Ich habe immer mit den Sockets gearbeitet, doch mittlerweile gibt es mehrere Gründe, die für INDY sprechen. Ich habe mir dieses Tutorial zur Brust genommen, allerdings hapert es etwas:

Mehrmal im Tutorial gibt es unter den Funktionen im OnExecute des Servers folgendes:

  AThread.Connection.ReadBuffer(Result, SizeOf(Result)); {  oder ähnliche Kombinationen, auch mit "WriteBuffer" } Allerdings scheint das einen ältere Indy-Version zu sein, den "AThread" ist ja jetzt "AContext":

  AContext.Connection.IOHandler.Write(Result, SizeOf(Result)) {  Das hier wäre die neue Version, allerdings gibt es kein ReadBuffer bzw. WriteBuffer mehr. Das reine "Write" geht aber auch nicht.  } Jetzt suche ich die Alternative für Read-/WriteBuffer

Danke,
Lukas

[stahli]

Das könnte Dir helfen: http://www.delphipraxis.net/170904-i...bertragen.html

[ByTheTime]

Ja danke, hatte in letzter Zeit nicht so viel Zeit. Ich hab es mir mal angeschaut. Sieht nach etwas arbeit aus, das alles umzustellen. Da ich dafür im Moment nicht so viel Zeit habe, bleib ich erstmal bei den Sockets. Mal sehen, wenn ich das alles so hinbekomme, dann lade ich vllt. mal das ganze hoch, dann sollte es auch kein Problem mit INDY 10 mehr geben und es gibt eine aktuelle Version hier im Forum. Aber das steht leider im Moment nicht an erster Stelle. Aber DANKE!

[ByTheTime]

Ist zwar schon ewig her, aber ich schreibe trotzdem nochmal. Zwar hab ich mir das ganze Angeschaut, aber wirklich weiter komme ich damit nicht. Mit Indy habe ich bis jetzt nicht viel Erfahrung, und gerade das Tutorial von oben, schien mir dafür perfekt, da ich eine auf Sockets basierende Anwendung gerne auf die Indy umstellen würde. Dafür schien mir das mit den Kommando Bytes sehr passend. Aber ich kann auch nirgendso im Internet ein Tutorial oder ähnliches für einen Kommando-Indy Chat finden.

[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.