Hi,

Also, ich werde aus der Methode Read nicht schlau. Nachdem ich die Hilfe-Funktion um Rat gefragt habe schwirrten mir noch mehr Fragezeichen im Kopf herum. In den Tutorials, die ich gefunden habe stand auch nichts darüber.
Wozu muss der Client aus der Verbindung lesen? Ist dafür nicht TServerSocket zuständig?
Wäre super, wenn mir jemand diese Methode genau erläutern könnte.


Aus der Hilfe:

Zitat:

TCustomSocket.OnRead Ereignis Tritt ein, wenn ein Client-Socket Informationen aus der Socket-Verbindung lesen soll. Klasse TCustomSocket Syntax [Delphi] property OnRead: TSocketNotifyEvent; Beschreibung Schreiben Sie eine Behandlungsroutine für das Ereignis OnRead, um aus der Socket-Verbindung zu lesen. Handelt es sich um einen blockierenden Socket, muss zum Lesen aus der Verbindung ein TWinSocketStream-Objekt verwendet werden. Andernfalls verwenden Sie zur Ausführung des Lesevorgangs die Methoden des Parameters Socket. Hinweis: Nicht-blockierende Sockets erhalten nicht immer ein OnRead-Ereignis für das letzte Bit der über die Verbindung übergebenen Daten. Bei nicht-blockierenden Sockets sollten Sie daher im Ereignis OnDisconnect überprüfen, ob nicht gelesene Daten vorhanden sind.

Moin!

Balmung der blaue Gott hat folgendes geschrieben:

Wozu muss der Client aus der Verbindung lesen? Ist dafür nicht TServerSocket zuständig?

Hast du dich schonmal gefragt, wie der Server Daten an den Client schicken soll? Haste dir auch dieses Tut mal angesehen?

cu
Narses

Narses hat folgendes geschrieben:

Hast du dich schonmal gefragt, wie der Server Daten an den Client schicken soll? Haste dir auch dieses Tut mal angesehen? Narses

In den Tutorials stand, man macht ein CLientSocket und ein ServerSocket und lässt sie an einem Port horchen. Der Server ist dabei für das Empfangen zuständig. Aber eigentlich beantwortet das schon eine meiner Fragen. Ich werd mir das Tut noch anschauen, danke.

Ich hab aber noch nicht verstanden, was das bedeuted:

Zitat:

Nicht-blockierende Sockets erhalten nicht immer ein OnRead-Ereignis für das letzte Bit der über die Verbindung übergebenen Daten.

Moin!

Balmung der blaue Gott hat folgendes geschrieben:

In den Tutorials stand, man macht ein CLientSocket und ein ServerSocket und lässt sie an einem Port horchen. Der Server ist dabei für das Empfangen zuständig.

Spannende Formulierung (was ist´n das für´n Tut gewesen... ); gemeint ist mit

komisches Tutorial hat folgendes geschrieben:

Der Server ist dabei für das Empfangen zuständig.

dass der Server ankommende Verbindungen annimmt, also die Clients melden sich beim Server und nicht umgekehrt.

Balmung der blaue Gott hat folgendes geschrieben:

Ich hab aber noch nicht verstanden, was das bedeuted: Zitat: Nicht-blockierende Sockets erhalten nicht immer ein OnRead-Ereignis für das letzte Bit der über die Verbindung übergebenen Daten.

Das ist leider auch nicht so ganz einfach zu erklären grob vereinfacht: es wird unter Umständen für das letzte Byte, dass in der Verbindung "hängt" kein OnRead-Ereignis mehr ausgelöst. wobei das in der Praxis sehr selten sein dürfte; betrifft auch nur Lesevorgänge, die weniger als den aktuellen Pufferinhalt auslesen; die WSA erzeugt dann ein weiteres FD_READ, nur eben manchmal nicht, wenn nur noch ein Byte über bleibt; Fazit: man sollte immer alles aus dem WSA-Buffer lesen, z.B. mit .RecieveText oder so

cu
Narses

Narses hat folgendes geschrieben:

Spannende Formulierung (was ist´n das für´n Tut gewesen... ); gemeint ist mit komisches Tutorial hat folgendes geschrieben: Der Server ist dabei für das Empfangen zuständig. dass der Server ankommende Verbindungen annimmt, also die Clients melden sich beim Server und nicht umgekehrt.

Naja, in dem Tut (www.dsdt.info/tutorials/winsocket/?page=4) nimmt halt tatsächlich nur das Sockets des Servers Nachrichten entgegen. Mir ist aber klar geworden, dass man so eine extreme Trennung von Server und Client nicht braucht. Also falls der Client Daten entgegennehmen soll, muss man dafür kein Objekt des Typs TServerSocket verwenden, sondern kann dafür TClientSocket verwenden.

Narses hat folgendes geschrieben:

grob vereinfacht: es wird unter Umständen für das letzte Byte, dass in der Verbindung "hängt" kein OnRead-Ereignis mehr ausgelöst. wobei das in der Praxis sehr selten sein dürfte; betrifft auch nur Lesevorgänge, die weniger als den aktuellen Pufferinhalt auslesen; die WSA erzeugt dann ein weiteres FD_READ, nur eben manchmal nicht, wenn nur noch ein Byte über bleibt; Fazit: man sollte immer alles aus dem WSA-Buffer lesen, z.B. mit .RecieveText oder so

Das reicht mir erst mal als Erklärung, bis ich mich irgendwann mal für diese Lesevorgänge interessiere.

Danke für deine Hilfe.

PS: Dein Tutorial find ich spitze

Moin!

Balmung der blaue Gott hat folgendes geschrieben:

Naja, in dem Tut (www.dsdt.info/tutorials/winsocket/?page=4) nimmt halt tatsächlich nur das Sockets des Servers Nachrichten entgegen.

Das aus didaktischen Gründen zunächst mal so zu machen, ist ja auch nicht verkehrt, aber nicht zuende erklärt...

Balmung der blaue Gott hat folgendes geschrieben:

Mir ist aber klar geworden, dass man so eine extreme Trennung von Server und Client nicht braucht.

Vielmehr: so eine extreme Trennung ist einfach falsch.

Balmung der blaue Gott hat folgendes geschrieben:

Also falls der Client Daten entgegennehmen soll, muss man dafür kein Objekt des Typs TServerSocket verwenden, sondern kann dafür TClientSocket verwenden.

Wie schon gesagt, nicht nur "kann", sondern "muss". Client/Server-bezogen ist lediglich der Verbindungsaufbau, die Datenübertragung findet (bei TCP) immer in beiden Richtungen statt und macht auch eigentlich nur so Sinn.

Balmung der blaue Gott hat folgendes geschrieben:

PS: Dein Tutorial find ich spitze

Danke! (schätze, du meinst das Protokoll-Chat-Tut, oder?)

cu
Narses