Discussion :

[Coussati]

salut

j'essaie de créer un tchat parfait et propre et j'ai un petit problème :

j'aimerais gérer le client qui a décidé de se déconnecter afin de le retirer de a liste des clients online et annoncé la déconnexion du client sur lee tchat par ex

j'utilise les compo de WASockets de waskol

j'espère qu'il verra mon poste

[LadyWasky]

Tada ! me voilà !

Les sources du Tchat sont là :
Socket bloking ? Exemple de tchat ?

Tu as aussi des sources dans ce fil :
[Sockets/Sendbuf]Logiciel de chat


d'autres liens qui pourront t'aider :
- La gestion des erreurs : http://www.developpez.net/forums/d38...tclientsocket/

A+

[Coussati]

merci, c'est bien la source que je cherchais; par contre ça ne m'aidera pas car l'exemple est trop simple

mon appli, c'est un tchat avec authentification user / pass à une base de donnée (juste pour dire que chaque utilisateur à un pseudo)

etdonc, lorsqu'un client se déconnecte, comment le server peut savoir quel pseudo qui s'est deco, et ensuite le dire aux autres clients afin de le retirer des personnes online

[Coussati]

waskol ? les autres ?

[LadyWasky]

Je ne t'ai pas oublié, mais le programme est plus simple que l'explication. Il faut que je retrouve mes petits.

Bon, tu peux t'en sortir assez simplement avec mes composants
Tu vois TregistryServer et TRegistryClient ?

TWARegistryServer, à mettre sur le serveur, permet de gérer des comptes utilisateurs qui seront enregistrer dans la base de registre (ou ailleurs !) du serveur et TWARegistryClient permet à une machine cliente de gérer un compte utilisateur i(identifié par AccountName) avec diverses données texte qui peuvent lui être liées (mot de passe, Nom, Prénom, Adresse-email par exemple).
En fait même si ça s'appelle TWARegistryXXXX, ça n'écrit ni ne lit rien dans la base de registre du serveur.
Tout est intercepté, coté serveur dans
OnChangeAccountName, OnRegRead et OnRegWrite


TWARegistryServer
OnRegWrite(Sender: TObject; Socket: TSocket; AccountName, RegPath, AValue,AData:string) :
Quand le serveur reçoit OnRegWrite, c'est que le client transmet des données (AValue) au serveur à enregistrer quelque part pour le compte de "AccountName"
Tu peux choisir d'enregistrer ces données dans une base de registre, un fichier texte ou bien dans une base de données, ou bien de ne rien faire du tout (compte non valide, ou champ de donnée qui n'existe pas par exemple).
RegPath indique un chemin (dans l'arborescence de la base de registre, vers un répertoire du disque dur).
En fait, tu peux t'en servir pour transmettre n'importe quoi, ça peut servir d'indicateur, transmettre une adresse IP, etc..
En fonction de cette valeur, tu peux donc gérer un comportement particulier sur ton serveur.
AValue te permet d'identifier le champ (NOM, PRENOM, AGE, EMAIL, PWD) qui est concerné par la mise à jour.
AData est la donnée à écrire.

OnRegRead(Sender: TObject; Socket: TSocket; AccountName, AnswerID, RegPath, AValue:string)
C'est tout comme OnRegWrite, sauf que là, le client attend une réponse, il te dis quel champ (AValue), où ça se trouve (RegPath) et pour quel compte (AccountName) et attend une donnée qui lui sera renvoyée avec

WriteReply(Socket : TSocket;AnswerID,AData:string);

Tu remarqueras le AnswerID : très important !
Le client peut en effet envoyer plusieurs demande d'affilée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
if TWARegistryClient1.Connected then
begin
  //RegRead(AccountName, AnswerID, RegPath, AValue:string);
  RegRead('Waskol', 1, '', 'NOM');
  RegRead('Waskol', 2, '', 'PRENOM');
end;

Qui, grace aux aleas du TCP ne seront pas forcément reçues dans l'ordre approprié !
Du coup, le serveur répondras avec l'ID qu'il à reçu de la part du client, pour que le client sache exactement à quelle question correspond la réponse en retour.

Donc, coté serveur (façon Base de données) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
procedure Form1.WARegistryServer1OnRegRead(Sender: TObject; Socket: TSocket; AccountName, AnswerID, RegPath, AValue:string);
Var UneValeur:string;
begin
  Table1.Locate('USERID',AccountName,[]);
  UneValeur:=Table.FieldByName(AVALUE).asString;
  //WriteReply(Socket : TSocket;AnswerID,AData:string);
  WriteReply(Socket,AnswerID,UneValeur);
end;

Et côté client, on reçoit la réponse :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
procedure Form1.WARegistryClient1OnRegReply(Sender: TObject; Socket: TSocket; AnswerID, AData:string);
begin
  Case AnswerID of
  1:EditNom.text:=ADATA; //On a reçu le NOM
  2:EditPrénom.text:=ADATA;//On a reçu le Prenom
  end;
end;

On peut aussi utiliser la technique du "Case AnswerID of" côté serveur, bien sur.


Enfin, Pour résumer, côté Client Le principe est le suivant :
Une fois connecté le client dispose de trois possibilités.
- Changer le nom de compte utilisateur : ChangeAccountName()
- Demander à écrire ou mettre à jour une donnée : RegWrite()
- Demander à récupérer une donnée : RegRead();
_________________________________________________
Après ce petit cours sur ces deux composants, ça nous amène à ceci :

1ere Solution :
1) on peut utiliser RegistryClient.ReadReg() pour vérifier que le mot de passe proposé par l'utilisateur corresponde à ce qui se trouve sur le serveur avant d'ouvrir le tchat avec TTCPClient.Open;
2) Au moment de la vérification du mot de passe, côté serveur, on identifie l'adresse IP du client avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TWATRegistryServer.SocketToAddress(Socket)

on profite donc de ce moment pour stocker alors dans une TStringList (grace aux possibilité Names et Values de TStringList), d'un côté l'adresse IP et de l'autre, (l'idéal, côté serveur, c'est de faire ça grâce au composant TValueList Editor)
3) Du coup, quand le client se connecte pour de bon avec TTCPClient, ton serveur connaît, grace à l'adresse IP de celui qui se connecte.

Bon, là, c'est qu'il n'y aura qu'un seul compte ouvert par machine (par adresse IP).

2ème Solution :
1) Le client s'identifie avec RegistryClient
2) Le client se connecte au TChat avec TTCPClient
dans l'évènement OnConnect, on récupère le numéro de Socket Local (qui doit être le même côté client et côté serveur), grace à TTCPClient.SocketToAddressIn.
3) On transmet cette valeur au serveur aux coté du AccountName grace au TRegistryClient
4) le Serveur récupère cette valeur et permet d'identifier quel Utilisateur se connecte quand c'est tel ou tel Socket Local qui envoie des données.

3ème solution :
Quand tu envois des données avec TTCPClient,
Tu formates tes données comme ceci avant de les envoyer :
DonneesAEnvoyer:=UTILISATEUR+'#'+Message;

Imaginons que tu demande à ton client d'envoyer un premier message contenant le nom d'utilisateur, qu'est ce qui t'empêche côté serveur de savoir si oui ou non ce nom d'utilisateur est déjà présent dans une liste (un tableau) : rien.
Si l'utilisateur, n'existe pas, tu mets dans ton tableau, le nom de l'utilisateur et son numéro de "socket" associé (Tu en profites pour que ton serveur dise à tout le monde que "Machin" s'est connecté)
Puis quand le client se déconnecte tu cherches dans ta liste quel Nom d'utilisateur correspond au socket qui s'est déconnecté

Enfin bref, tu un champ de possibilités immense je trouve, et il va falloir que tu fasses preuve d'un peu d'imagination.

Celà dit !
Le tchat, tu peux le faire que avec TRegisryCLient et TRegistryServer.

[Coussati]

salut

t'inquiètes je n'ai pas zapper ton super poste, bien au cntraire j'essayais de bosser dessus, mais il y a pas malde chose que je ne métrise pas ... (malgré ton explication )

déjà les compo "Registry" je ne connais pas ... dans ton compo j'utilise que WATCPClient1 et WATCPservert1 donc les autres je ne sais meme pas comment marche ...

mais bon si c'était pour me donner une manière de gérer l'authentification dans le tchat, c pas un prob, j'ai déjà géré celà, tout est ok de ce coté là

mon prob se situe au niveau des deco



puis ton idée n'est pas mal :

3ème solution :
....
Si l'utilisateur, n'existe pas, tu mets dans ton tableau, le nom de l'utilisateur et son numéro de "socket" associé (Tu en profites pour que ton serveur dise à tout le monde que "Machin" s'est connecté)
Puis quand le client se déconnecte tu cherches dans ta liste quel Nom d'utilisateur correspond au socket qui s'est déconnecté

mais dans ce cas : comment à la connexion avoir ce n° de socket unique ?

en regardant la source qui était fournit avec ton compo jai remarqué "le port local" ==> Server.PeerToPort(Socket)

est ce que c de çaque tu parles ?

en tout cas ce "port local" m'intrigue bien et j'aimerais quelques infos dessus

car on dirait que le n° est unique ... et tout bizzarement même après avoir fermé / ouvert le server les n° ne sont pas les même ...

je me demande si je ne devrait pas les utilises comme une "clé" unique, ou des doublons peuvent exister ? :/

en tout cas, s'il y a un truc qui permet d'identifier chaque client à la connexion, et chaque client à la deconnexion, je pense pouvoir déterminer quel pseudo est déconnecté

confirme moi tout ça stp


re ... en regardant la source je vois en plus de port local, socket local

donc c'est bien, ça !il me faut à la connexion et à la déconnexion un même chiffre / nombre unique !

j'associerai les pseudo online avec les n° et donc une fois que j'aurai le n° deco, je saurai quel pseudo est deco

dsl si je ne suis pas très claire ce soir, il est 4h45 lol