Client-Verbindung trennen

schippi · Beiträge: 23

Hallo!
ich benutze gerade die TNBFPA-Socket Komponente vom Narses. Funktioniert auch alles super!
Jetzt will ich aber nachdem der Client was an den Server gesendet hat, etwas zurück an den Client senden und danach die Verbindung zum Client trennen. Das klappt aber bei mir net.
Irgendwie müsste ich halt überprüfen ob schon alle Daten an den Client gesendet wurden. Wenn alle Daten gesendet wurden --> trenne Verbindung. (Wichtig ist das der Server die Verbindung trennt)
Weiß jemand wie das geht?

Viele Grüße!

Narses · Verfasst: Mi 17.10.07 12:43

Moin und

im Forum!

schippi hat folgendes geschrieben:

Jetzt will ich aber nachdem der Client was an den Server gesendet hat, etwas zurück an den Client senden und danach die Verbindung zum Client trennen. Das klappt aber bei mir net.
Irgendwie müsste ich halt überprüfen ob schon alle Daten an den Client gesendet wurden. Wenn alle Daten gesendet wurden --> trenne Verbindung. (Wichtig ist das der Server die Verbindung trennt)

Das geht nicht so ohne weiteres nur im Server (wenn das wirklich auf den Punkt gebracht sein muss, dann geht das so exakt nur mit blocking-socket-calls und Threads; aber normalerweise ist das nicht notwendig). :nixweiss:

Ansatz für eine elegante Lösung: Definiere ein "QUIT"-Kommando, dass du nach dem Empfang der Daten im Client an den Server sendest. Erhält der Server dieses Kommando, dann trennt er einfach die Verbindung. So stellst du sicher, dass der Datenempfang im Client vollständig ist, aber trotzdem der Server die Verbindung trennt. :idea:

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

schippi · Beiträge: 23

Danke erstmal für die tolle Begrüßung :wave:

Also wenn das nicht so einfach geht dann lass ichs halt, weil ich müsste was machen, bei dem sich der Client mit dem Server verbindet und ihm Daten schickt. Der Server schaut sich die Daten an und überprüft dann, ob er die Daten weiterverarbeitet oder den Client rausschmeißt. Wenn er ihn rausschmeißt, soll er ihm halt vorher sagen, woran's gelegen hat.
Wenn ich das jetzt mit dem Quit-Commando mache, dann würde sich der Client ja im Prinzip wieder selbst rauswerfen.

Oder wird das vielleicht üblicherweise so gemacht, dass wenn der Client keine Berechtigung mehr hat, er sich eigentlich selbst rausschmeißt. :gruebel:

Weil einfacher wärs ja..

Danke

Narses · Verfasst: Mi 17.10.07 14:04

Moin!

schippi hat folgendes geschrieben:

Also wenn das nicht so einfach geht dann lass ichs halt, weil ich müsste was machen, bei dem sich der Client mit dem Server verbindet und ihm Daten schickt. Der Server schaut sich die Daten an und überprüft dann, ob er die Daten weiterverarbeitet oder den Client rausschmeißt. Wenn er ihn rausschmeißt, soll er ihm halt vorher sagen, woran's gelegen hat.

Du willst also eine Authentifikation abbilden ("login"), richtig? Dann ist die Antwort ja nicht soo lang (konkret <8kb, dann passt´s in den WSA-Buffer) und sollte eigentlich korrekt empfangen werden. Ein typischer Codeschnipsel könnte so aussehen (Ausschnitt von hier):

markieren

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:

// Eine Kommandosequenz aus einer Clientverbindung bearbeiten
procedure TServerMain.NBFPAServer1ClientExecute(Sender: TObject; PA: TProtocolAdapter);
  var
    Cmd: TCmdSeq;
    i: Integer;
begin
  case PA.CurrentToken of
    CMD_VERSION: // ------------------------------------------------------------
      begin
        if (PA.Inbound.Strings[1] = APP_ID) then // Anwendung OK?
          if (PA.Inbound.Strings[2] = APP_VER) then begin // Version OK?
            //...
          end
          else begin // Version ist NICHT OK!
            Cmd := TCmdSeq.Create(CMD_SAID);
            Cmd.Add(APP_ID);
            Cmd.Add('Version inkompatibel!');
            PA.Outbound.AddCmdAndFree(Cmd);
            PA.Send;
            Application.ProcessMessages;
            PA.Disconnect;
          end
        else // kein GameChat-Client?!
          PA.Disconnect; // direkt auflegen
      end;

Wirklich schwer wird das nur, wenn du nach einer größeren Datenmenge punktgenau im Server auflegen willst! :idea:

schippi hat folgendes geschrieben:

Wenn ich das jetzt mit dem Quit-Commando mache, dann würde sich der Client ja im Prinzip wieder selbst rauswerfen.

Ja, was auch konzeptionell nicht unbedingt soo verkehrt ist. Ich würde eine authentifizierte Verbindung so abbilden:
- Die Session ist im Zustand "authentifiziert" oder "nicht auth."
- Kommandos werden nur in Sessions ausgeführt, die im Zustand "auth." sind, sonst Fehlermeldung
- Ausnahme: Anmeldekommando wird auch im Zustand "nicht auth." akzeptiert
- Wird die Client-Anmeldung nicht akzeptiert, gibt´s eine Ausgabe
- Wenn der Client "keine Lust" mehr hat, legt er halt auf
- Wenn der Server meint, jetzt ist genug, legt er halt auf, Meldungen gab´s ja schon vorher
:nixweiss:

schippi hat folgendes geschrieben:

Oder wird das vielleicht üblicherweise so gemacht, dass wenn der Client keine Berechtigung mehr hat, er sich eigentlich selbst rausschmeißt. :gruebel:

Weil einfacher wärs ja..

Ja, s.o., besonders bei binären Protokollen übernimmt ja der Client eh die Kontrolle über die Verbindung. Bei benutzerinteraktiven Protokollen (wie z.B. Telnet etc.) ist das was anderes, hier werden ja Benutzereingaben direkt vom Server verarbeitet. Beim NBFPA-Protokoll ist aber immer das Programm als "Filter" dazwischen.

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

schippi · Beiträge: 23

Jup, ist eine Art Login und auf 8 kB komm ich lang net. Deswegen werd ich das so machen.
Danke für die super Infos!! :zustimm:

Viele Grüße
schippi

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme