To Block or not to Block. Frei nach WS

[Mavarik]

Hallo Zusammen!

Ich arbeite hin und wieder mit der TSock Unit von Ward van Wanrooij. Hier steht im Header, dass für einen Server Blocking das richtige wäre...

Zitat:

Zitat von Ward van Wanrooij

I strongly recommand against using non-blocking sockets for normal server applications,
see 'Using threads' in Delphi help.

Da ich nix in der Delphi Hilfe gefunden habe, hier die Frage:

Warum soll ich auf meinem Server pro Socket einen Thread mit Endlosschleife laufen lassen, wenn im non-Blocking bereich einfach gewartet werden kann, bis der event feuert? Oder habe ich da etwas falsch verstanden.


Frank :gruebel:

[Mavarik]

Push! Keiner ne Antwort oder Meinung?

Frank

[marabu]

Hallo Frank,

Zitat:

Zitat von Mavarik

Warum soll ich auf meinem Server pro Socket einen Thread mit Endlosschleife laufen lassen, wenn im non-Blocking bereich einfach gewartet werden kann, bis der event feuert? Oder habe ich da etwas falsch verstanden.

kann es sein, dass du non-blocking mit asynchronous i/o verwechselst? Non-blocking heißt lediglich, dass dein Programm die Kontrolle sofort zurück erhält - das Ergebnis erhältst du später durch polling.

Grüße vom marabu

[Mavarik]

Ja eben...bzw. nein :stupid:

Blocking

Der Server startet für jede Verbindung einen eigenen Thread der in einer Endlosschleife wartet...

Delphi-Quellcode:

while NewSock.Connected do
    try
      Sleep(100);
      Command:=NewSock.ReceiveLine();
      //ReceiveLine returns when:
      // BlockingTimeout expires (return value=''), or
      // data has been received, but no full line (return value=''), or
      // data has been received, full line (return value=full line)
      if Command<>'' then
      begin
        LogBox.Items.Insert(0, 'Receive: '+Command);
        if (UpperCase(Command)='DATE') then
          NewSock.SendLine(DateTimeToStr(Now))
        else if (UpperCase(Command)='QUIT') then
          NewSock.Close
        else
          NewSock.SendLine('Unknown or no command received. Valid commands are: DATE , QUIT');
      end;
    except
      on E:ESockException do LogBox.Items.Insert(0, 'Exception: '+E.Message);
    end;

Nonblocking

Der Server kann sich mit sich selber beschäftigen, bis der entsprechende event diese Procedure aufruft.

Delphi-Quellcode:

procedure TMainForm.MasterSockRead(Sender: TObject; Count: Integer);
var
  Command: String;
  NewSock: TSock;
begin
  NewSock:=(Sender as TSock);
  try
    Command:=NewSock.ReceiveLine;
    if (Length(Command)>0) then
    begin
      LogBox.Items.Insert(0, 'Receive: '+Command);
      if (UpperCase(Command)='DATE') then
        NewSock.SendLine(DateTimeToStr(Now))
      else if (UpperCase(Command)='QUIT') then
        NewSock.Close
      else
        NewSock.SendLine('Unknown command. Valid commands are: DATE , QUIT');
    end;
  except
    on E:ESockException do LogBox.Items.Insert(0, 'Exception: '+E.Message);
  end;
end;

Frank :coder:

(Aus den Beispielprogrammen)

[marabu]

Hallo Frank,

Zitat:

Zitat von Mavarik

Ja eben...bzw. nein

Blocking: Der Server startet für jede Verbindung einen eigenen Thread der in einer Endlosschleife wartet...
Nonblocking: Der Server kann sich mit sich selber beschäftigen, bis der entsprechende event diese Procedure aufruft.

wie immer entstehen ohne vorherige Begriffsbestimmungen die tollsten Missverständnisse. Ich beziehe mich auf Winsock 2 und du dich auf TSock. Ich kenne mehrere verschiedene socket i/o Techniken. Eine davon ist blocking und ist über jeden Definitionszweifel erhaben. Die anderen sind alle non-blocking. Wiederum davon wird der trivialste Modus als non-blocking bezeichnet (oft auch als pure non-blocking) und auf diesen bezog ich mich in meinem Beitrag. Die restlichen Modi bedürfen weiterer Erklärungen.

Ich habe mir die Unit TSock besorgt und mir den Code kurz angesehen. Ich komme zu dem Schluß, dass es sich um eine Implementierung von asynchronous sockets handelt. Dabei sendet der protocol stack eine message (WM_SOCK), wenn sich was tut.

Die bloße Warnung vor dem non-blocking mode in TSock ist vielleicht etwas ungeschickt, aber der Autor wollte wohl nicht zu sehr ins Detail gehen. Nach meinen Informationen bricht die server performance mit asynchronous sockets recht bald ein.

Während ich hier schreibe habe ich im Netz einen wunderschönen Artikel von Warren Young gefunden, der dir eine Klassifikation der unterschiedlichen i/o modes nahe bringt. Darüberhinaus geht er etwas tiefer auf die Wahl des richtigen Modus ein. Viel Spaß beim Studium.

Schönes Wochenende

marabu

[Mavarik]

Ja Danke!

Werde es gleich mal lesen...

Danke

[Mavarik]

Hi!

Netter Text, sagt im Prinzip alles...

Das Problem ist jetzt eine Komponetet zu finden die eine asynchronen Threadgetriebenen Transfer für den Server hinkriegt. Und dann noch eine Event gesteuerte Client Komponente. Scheint schwieriger zu sein... :cry:

Teste gerade die 4. :pale:

Grüsse Frank :coder: