idTCPServer identifizieren eines bestimmten Clients

[Cyberaxx]

Hallo und guten Morgen

Ich habe vor langer Zeit mal eine Client / Server Kommunikation programmiert mithilfe der Socket Komponenten.
Da ist es sehr einfach einen Client zu Identifizieren.
Client verbindet sich, im Server kommt das OnConnect Ereignis und von da an hat der Client eine ID

Delphi-Quellcode:

ClientID := Integer(Socket);

Diese bekam der Client direkt zugesendet und über das Protokoll wird immer die ID mit übertragen. Dadurch das sie vom Server
kommt kann der Client eindeutig erkannt werden. Da ab dem Verbundenen Client alle Daten aller Clients zusammen gesetzt werden
und über das Protokoll bzw dem Protokoll Händler in einzelne Befehle geteilt werden. Gerade wenn die Daten nicht in einem Stück ankommen.

Jetzt bin ich dabei es umzustellen auf idTCPServer um es als Konsolen Anwendung zu umzubauen und kann/möchte auf Ereignisse ganz verzichten.
Der Client verbindet sich und sendet direkt den Befehl zum anmelden. Da hier das Ereignis fehlt, kann ich so keine ID vergeben, da ich mir nicht
mehr sicher sein kann von wem die Daten stammen, da die Daten eben in einem einzigen String stehen und vor dem sich gerade verbundenen Client
könnte eine Nachricht oder ein weiterer Login stehen.

Genau vor diesem Problem stehe ich gerade, ich möchte gerne dem Client der sich gerade verbunden hat, sagen was er als nächstes zu tun hat, nur wie?

Zitat:

Client sendet die Protokollversion
Server prüft die Protokollverion
-> Version OK --> Client soll Login senden
-> Version Falsch --> Client trennen

Wie kann ich es schaffen den Client zu identifizieren?

Gruß

Cyber

[Cyberaxx]

Hat niemand eine Idee? Bin ich vllt. auf dem Holzweg?
Soweit ich bisher mitbekommen habe laufen Ereignisse nicht in einer Konsole so ohne weiteres.

[uoeb7gp]

Hallo Cyberaxx, dies sind performance getestete Hochlast Client Server Anwendungen.
Synchrone und Asynchrone Librarys, Thread-Pooled und Cached.
Alles schön in DLL gekapselt, alles fix und fertig.
Versuchs einfach mal mit diesen, ist alles drin was Brauchst.

lg.

http://www.delphipraxis.net/download.php?id=41481
http://www.delphipraxis.net/download.php?id=41480

[Cyberaxx]

Danke für die Antwort. Habe sie mir runtergeladen und schaue sie mir mal an :)

[DataCool]

@Cyberaxx:
Du hast aber auch beim TIdTcpServer ein OnConnect Event, indem Du die Verifizierung ganz einfach
via ReadLn/WriteLn abwickeln kannst.

Greetz Data

[Cyberaxx]

Ja das weiß ich, mache ich ja mit dem TServerSocket auch nicht anders.
Das problem ist, das die Events in einer reinen Konsolen Anwendung nicht aufgerufen werden.
Genau das möchte ich ja umgehen ansonsten wäre ne Lösung recht nett, mit der ich die Events in der Konsole nutzen kann.

Cyber

[DataCool]

@Cyber:
Das sollte aber bei den Indys im Gegensatz zu den normalen Socket Komponenten trotzdem funktionieren(Events).

Greetz Data

[Cyberaxx]

Nachher mal testen, hatte es erst gar nicht nochmals versucht.
Melde mich nachdem ichs angetestet hab.

[Cyberaxx]

Hallo

Ich habs nun einmal getestet.

Delphi-Quellcode:

program Project2;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  idTCPServer,
  idGlobal;

type
  TServer = class(TObject)
  private
    FIdServer: TIdTCPServer;
    procedure FIdServerConnect(AThread: TIdPeerThread);
    procedure FIdServerExecute(AThread: TIdPeerThread);
    procedure FIdServerDisconnect(AThread: TIdPeerThread);
  public
    constructor Create;
    destructor Destroy;
  end;

const
  Servername = 'TEST';

var
  FServer: TServer;
  ValEingabe: string;

{ TServer }

constructor TServer.Create;
begin
  FIdServer := TIdTCPServer.Create(nil);
  FIdServer.OnConnect := FIdServerConnect;
  FIdServer.OnDisconnect := FIdServerDisconnect;
  FIdServer.OnExecute := FIdServerExecute;
  FIdServer.DefaultPort := 55443;
  FIdServer.Active := True;
end;

destructor TServer.Destroy;
begin
  FIdServer.Active := False;
  FIdServer.Free;
end;

procedure TServer.FIdServerConnect(AThread: TIdPeerThread);
  var
    SID: Integer;
begin
  SID := Integer(AThread);

  Writeln('Client Connected ' + InttoStr(SID));
end;

procedure TServer.FIdServerDisconnect(AThread: TIdPeerThread);
begin
  WriteLn('Client Disconnected ' + AThread.Connection.Socket.Binding.IP);
end;

procedure TServer.FIdServerExecute(AThread: TIdPeerThread);
begin
  Sleep(10);
end;

begin
  WriteLn('Starte');

  FServer := TServer.Create;

  repeat
    Readln(ValEingabe);
  until UpperCase(ValEingabe) = 'EXIT';

  FServer.Free;
end.

Was ich aber nun noch gerne wissen möchte, warum werden Events nicht vom ServerSocket ausgeführt?
Dies war ja für mich der Grund warum ich es umstellen wollte, gehört also noch zum aktuellen Problem. :)

Danke @DataCool Hätte es sonst nicht noch einmal getestet, da man meist liest, das es nicht Problemlos gehen würde.
Cyber

[DataCool]

@Cyber:

Die normalen Sockets arbeiten mit Windows Events,
deshalb brauchen diese eine Form oder ähnliches damit die Windows Messages
empfangen und weiter geleitet werden können.

Bei den Indys ist das ganze anders gelöst, damit man auch mal einen Server als Konsole schreiben kann ;-)
Nein, nicht nur deswegen, die ganze Architektur der Indys ist anders aufgebaut und das ist gut so :-D

Nachtrag:
Nur als Tip für den Indy "Neuling/Umsteiger" :
Das OnExecute Event wird innerhalb eines Threads ausgeführt und trifft solange immer wieder ein bis die Verbindung getrennt wird.

Wie Du an dem Parametern AThread : TIdPeerThread erkennen kannst, verwendest Du Indy9 dort wird für jeden Client ein eigener Thread erzeugt.
Solltest Du allerdings plannen einen "Hochleistungsserver" mit sehr sehr vielen gleichzeitigen Verbindungen zu schreiben, würde ich den Umstieg auf Indy10
empfehlen, wo mit einem Threads Pool gearbeitet wird.


Greetz Data