AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke Delphi Indy TCP (cmd) Server/Client
Thema durchsuchen
Ansicht
Themen-Optionen

Indy TCP (cmd) Server/Client

Ein Thema von Dragon27 · begonnen am 17. Aug 2009 · letzter Beitrag vom 17. Aug 2009
Antwort Antwort
Dragon27

Registriert seit: 20. Nov 2003
Ort: Aßling
543 Beiträge
 
Delphi XE6 Enterprise
 
#1

Indy TCP (cmd) Server/Client

  Alt 17. Aug 2009, 16:40
Hallo zusammen,

im Moment beschäftige ich mich ein wenig mit den Indys und verwende einen IdcmdTCPServer und einen idTCPClient. Verbindung etc. steht und man kann senden und empfangen.
Nun habe ich aber ein paar Fragen auf die ich Antworten suche.

1. Der Client schickt ja an den Server ein Command und holt sich dann praktisch das Ergebnis beim Server ab.

Das habe ich so gelöst:
Delphi-Quellcode:
client.Connect;
client.SendCmd('version');
memo1.Lines.Text:=Client.IOHandler.ReadLn();
client.Disconnect;
Ist das soweit okay und voralledem ist das Ganze zuverlässig? Ich meine, was ist wenn der Sever nicht gleich die Daten parat hat, da es viele Anfragen gibt? Wartet der Client dann?

2. Wie Ihr oben seht, Connected und Disconnected der Client immer wieder. Auch bei den meisten Beispielen wird das so gehandhabt. Muss man das machen oder kann man auch
nur einmal beim Programmstart connecten und die Verbindung bleibt dann stabil?


3. Falls die Verbindung bestehen bleibt, also nicht bei jedem Befehl getrennt wird, wie kann ich den die Clients am besten unterscheiden? Bei den Sockets gab es ja einen Index
wie ist das bei den Indys? Bei "ASender: TIdCommand" beim Server habe ich keine Unterscheidungsmöglichkeit auf anhieb gesehen.


Recht herzlichen Dank für Eure Hilfe!


P.s.: Ich verwende Indy 10
Delphi is ......... DELPHI!!
  Mit Zitat antworten Zitat
Benutzerbild von ghost007
ghost007

Registriert seit: 31. Okt 2005
Ort: München
1.024 Beiträge
 
Delphi 7 Personal
 
#2

Re: Indy TCP (cmd) Server/Client

  Alt 17. Aug 2009, 18:53
Servus, Dragon27!

zu 1:
Ja es ist zulässig. der client wartet beim readln solange(die app freezt) bis etwas vom server kommt.
Deswegen lagert man normalerweise die komplette client komponennte in einen thread aus.

zu 2:
Kann man auch einmal beim start connecten und dann ist das ding stabil bis einer von beiden den löffel abgibt.

zu 3:
Am besten du legst in der server app einen array of TidContext (irgendwie so muss das heißen ^^) an und speicherst in dem onConnect des servers den context ab. Der is für jeden client individuell. (Wenn du mehere clients hinter dem gleichen router hast, also die gleiche incoming ip dann musst du dem client eine id geben und auf den ids basierend deinen traffic managen). Das speichern der clients mach ich immer mit einem record, der alle nötigen infos enthält.
Beispiel:
Delphi-Quellcode:
...
type
  TConnection = record
    id : Integer;
    IP : String;
    nick : String;
    con : TIdContext;
    ready : boolean;
  end;

type
  TConnections = array of TConnection;
...
var
  connections: TConnections;
...
MfG - Ghost007

//Edit: Hab dir mal meine clientthread unit angehängt, sie reagiert zwar nicht auf alle events, die kannst du dir ja im notfall noch ergänzen(Ich hab die nich gebraucht ^^).
Angehängte Dateien
Dateityp: pas clientthread_807.pas (2,0 KB, 57x aufgerufen)
Christian
Es gibt möglich Dinge und unmöglich Dinge.
Für unmögliche braucht man lediglich etwas länger.
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:34 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz