Autor Beitrag
UGrohne
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Veteran
Beiträge: 5502
Erhaltene Danke: 220

Windows 8 , Server 2012
D7 Pro, VS.NET 2012 (C#)
BeitragVerfasst: Mi 11.01.06 07:24 
Der Titel ist etwas schwierig zu formulieren. Hier mal um was es geht:

IdTcpServer stellt ja ein Ereignis OnExecute bereit, das ausgelöst wird, sobald Daten von einem Client empfangen werden. Meine bisherige Vorgehensweise war, in diesem Event die Daten zu nehmen, zu verarbeiten und fertig. Die Prozedur wird dann beendet.

Jetzt habe ich aber in einem Beispiel für die Indys folgenden Quelltext gesehen:
ausblenden volle Höhe Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
procedure TForm1.IdTCPServerExecute(AContext: TIdContext);
var
  connected: boolean;
  line: string;
  connectionNumber: integer;
begin
  { [!] NOTE: since this is a simple example to show how SSL works, we did not bother to synchronize
              any of the VCL/display calls - remember that the VCL is NOT thread-safe! }


  { Find an open connection... [!] }
  connectionNumber:= 0;
  while (ledConnected[connectionNumber].Brush.Color = clOn) do inc(connectionNumber);

  ledConnected[connectionNumber].Brush.Color:= clOn;  { show that we're connected [!] }

  AContext.Connection.IOHandler.WriteLn('Hello');
  connected:= true;
  while connected do begin
    try
      line:= AContext.Connection.IOHandler.ReadLn;
      AContext.Connection.IOHandler.WriteLn('>>'+line);
      memo1.Lines.add(format('[%d] %s',[connectionNumber,line]));
      if (ansiUpperCase(line) = 'BYE'or (ansiUpperCase(line) = 'QUIT'then begin
        AContext.Connection.Disconnect;
        connected:= false;

      end{ if (ansiUpperCase(line) = 'BYE') or (ansiUpperCase(line) = 'QUIT') }
    except
      connected:= false;
    end{ try/except }
  end{ do while connected }

  ledConnected[connectionNumber].Brush.Color:= clOff;    { show that we've disconnected [!] }

end{ ID TCP SERVER EXECUTE }

Im hervorgehobenen Bereich sieht man, dass eine while-Schleife in diesem Event verwendet wird, bis der Client den Befehl zum Trennen gibt. Jetzt ist in mir die Frage aufgetaucht, was besser ist: Daten verarbeiten und fertig oder auf weitere Daten in einer while-Schleife zu warten.

Was verbraucht weniger Resourcen, was ist schneller? Läuft OnExecute in dem Verbindungsthread für den Client ab oder hat das Ausführen dieser Prozedur einen größeren Overhead?

Es geht vor allem um die Performance, das beides geht, ist mir klar ;-)
UGrohne Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Veteran
Beiträge: 5502
Erhaltene Danke: 220

Windows 8 , Server 2012
D7 Pro, VS.NET 2012 (C#)
BeitragVerfasst: Mi 11.01.06 07:37 
OK, eigentlich hab ich nun die Lösung meiner Frage in der Hilfe zu Indy gefunden:
Zitat:
The event handler can be used to interact with the client connection by read a command and/or writing a response dependent on the protocol in use for the session. When the command and/or response is handled, the event handler should be exited to allow the Scheduler to respond other client connections to the server. Using loops or polling inside the OnExecute event handler should be avoided to reduce the chance of interferring with the Scheduler for the server.

The preferred way to interrupt execution of the looped OnExecute event handler is to call the TIdContext.Connection.Disconnect method for the context instance.

Ich frage mich nur, wieso genau das in einer "offiziellen" (sie steht ja verlinkt auf der Projektseite) Demo von Indy gemacht wird?