loetmann - Fr 15.09.06 22:11
Titel: TServerSocket Reihenfolg OnClientRead vor/nach OnClientWrite

---

Hallo,

es ist Wochenende und ich hab Zeit zum proggen...

nun ich habe vor 2 Wochen angefangen mich mit Sockets zu beschäftigen.
Vorweg kein Indy ich hab Delphi 3.

So soweit funktioniert auch alles, Server starten Browser fragt an (Server.OnClientRead) und Server sendet Daten (Server.OnClientWrite). lokal.
Nun habe ich testweise von einem 2. Rechner im LAN mal den Browser gestartet und den Server angesprochen (http://192.168.0.5:80 -die 80 hätt ich auch weglassen können).

So ich dachte es tritt erst ein OnClientRead und dann das OnClientWrite - Ereignis ein. Hier war es auf einmal anders herum :-?

Nun ich könnte alle Befehle im OnClientRead reinpacken, aber das ist doch nicht Sinn der Sache, oder?

Die Frage:
Sollte bei Sockets immer erst das OnClientRead vor dem OnClientWrite auftreten oder ist das unabhängig?

Wenn ja ist das blöd, weil ich OnClientWrite wissen muß was der Browser mir übergeben hat. Und manuell kann ich kein OnClientWrite auslösen?

ich hoffe Ihr könnt mir die Frage beantworten (ja, die Suche wurde schon letztes WE ausgiebig benutzt ;-) )

ein Gruß
LM

Narses - So 17.09.06 11:34

---

Moin!

Hm, bist du sicher, dass du die Ereignisse der Sockets richtig interpretierst?

AFAIK tritt OnClientRead ein, wenn Daten aus der Verbindung eingetroffen sind und OnClientWrite, wenn der Socket bereit ist, weitere Daten senden zu können (laut DOH).

Achtung beim OnWrite: IMHO gibt´s da einen Bug, denn das Ereignis tritt nur nach dem Connect genau einmal ein, weil die Borland-Entwickler keinen weiteren WSAAsyncSelect anstoßen, was laut MSDN aber nach einer erhaltenen FD_WRITE-Nachricht nötig wäre.

Ansonsten habe ich deine Problemschilderung leider auch noch nicht so ganz verstanden... :? :gruebel: ;)

cu
Narses

loetmann - So 17.09.06 13:28

---

danke für die Antwort,

Zitat:

Hm, bist du sicher, dass du die Ereignisse der Sockets richtig interpretierst?

nicht wirklich.

Das Problem ist ich kann ja nicht sinvolles senden kann, ehe der Client eine vernüpftige Anfrage gesendet hat.

Das mit dem Bug ist schon mal gut zu wissen.

Ich mache es jetzt so das ich warte bis beide Ereignisse eingetrten sind und sende dann die Daten.

Ein Gruß
LM

Narses - Mo 18.09.06 00:18

---

Moin!

loetmann hat folgendes geschrieben:

Zitat: Hm, bist du sicher, dass du die Ereignisse der Sockets richtig interpretierst? nicht wirklich.

Scheint mir ehrlich gesagt auch so. ;) Wobei ich das einschränken muss, da ich nicht 100%ig sicher weiß, ob die Sockets bei D3 auch exakt genau so funktionieren, wie ab D6 (ab da habe ich etwas Erfahrung). Ich gehe allerdings davon aus. ;)

loetmann hat folgendes geschrieben:

Ich mache es jetzt so das ich warte bis beide Ereignisse eingetrten sind und sende dann die Daten.

Das halte ich nicht für sinnvoll. Wenn du ein OnClientRead bekommst, kannst du auch Daten senden, was soll das OnClientWrite da noch helfen?

Wozu genau glaubst du das OnClientWrite zu brauchen? :gruebel:

cu
Narses

loetmann - Mo 18.09.06 00:40

---

Hallo,

Zitat:

Wozu genau glaubst du das OnClientWrite zu brauchen?

och da bin ich nach der Hilfe gegangen:

Zitat:

OnClientRead tritt ein, wenn der Server-Socket Informationen von einem Client-Socket lesen soll

Zitat:

OnClientWrite tritt ein, wenn der Server-Socket Informationen an einen Client-Socket senden soll

drum habe ich mir gedacht, warte erst einmal ab bis der Client Daten wirklich haben will.

Das ist natürlich blöd wenn erst das Write kommt und dann das Read.

Ich sehe das eher wie eine Freigabe, so wenn ich alle Daten vom Clienten habe und die Freigabe zu schreiben, schiebe ich die Daten zum Clienten (läuft über nem Thread*).

Jezt könnte es noch auftreten das nur ein Read oder nur ein Write kommt.... da mache ich aber ein Timeoutcheck und schließe die Verbindung wenn nichts mehr kommt.

*kein stThreadBlocking, mit ner Virtuellen Liste. Ich habs auch mal mit dem Server.ServerType:=stThreadBlocking probiert, aber das läuft etwas anders (aber wohl optimaler?) aber da muß ich noch mal die dokus durchwühlen ein Beispiel hab ich noch nicht gefunden (ich sollt mal die Chats angucken).

Ein Gruß
LM

Narses - Mo 18.09.06 00:51

---

Moin!

Genau da liegt dein "Denkfehler", der wohl leider durch die Übersetzung(?) der DOH zustande gekommen ist:

loetmann hat folgendes geschrieben:

Zitat: Wozu genau glaubst du das OnClientWrite zu brauchen? och da bin ich nach der Hilfe gegangen: Zitat: OnClientWrite tritt ein, wenn der Server-Socket Informationen an einen Client-Socket senden soll drum habe ich mir gedacht, warte erst einmal ab bis der Client Daten wirklich haben will.

Nochmal: OnClientWrite tritt ein, wenn der Socket bereit ist, Daten zu senden. Das hat nix mit einer Anforderung des Clients zu tun oder einer Aufforderung etwas zu senden. Es bedeutet lediglich, dass du jetzt etwas Senden könntest, wenn du wolltest - aber ganz unabhängig vom Client! ;)

Deshalb: OnClientRead tritt ein, du liest die Daten, verarbeitet diese und sendest die Antwort, fertig. OnClientWrite brauchst du eigentlich nur für extrem große Datenblöcke (um herauszufinden, wann du z.B. den Speicher wiederverwenden darfst) oder für Hintergrundtransfers (ereignisgesteuerte Datenpumpe).

cu
Narses

loetmann - Mo 18.09.06 19:02

---

Danke Narses,

OK das erklärt ja schon alles. So guck ich also ob der Socket bereit ist und wenn ich die Anforderung vom Clienten habe sende ich die Daten rüber.

Ein Gruß
LM