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

[LadyWasky]

JE te réponds dès que possible (ce soir ou demain soir, ok ?)

[Coussati]

ok, prend ton temps car g remarqué qu'il y a aussi "socket" qui génére un n°

donc il ne faut pas se tromper, il faut bien un n° qui est bien detecé aussi à la deco

[LadyWasky]

ok, prend ton temps car g remarqué qu'il y a aussi "socket" qui génére un n°

donc il ne faut pas se tromper, il faut bien un n° qui est bien detecé aussi à la deco

j'ai ma petite idée, on va gérer ça autrement...
plus simple, plus rapide : on va utiliser le côté obscur de mes composants

En attendant, lis attentivement ce qui est écrit ici :
http://www.developpez.net/forums/d15...logiciel-chat/

Comme ça tu comprendras l'idée.

[Coussati]

ok je vais voir

mais n'oublie pas ce qu'il nous faut "un code unique qui est généré à la connexion et est retrouvé par le server à la déco"

[Coussati]

bon je n'ai pas eu le temps d'analyser en detail ton poste, par contre j'ai testé un truc

dans chaque évènement il y a un paramètre "socket" de type cardinal

je trouverais logique qu'il soit unique pour chaque client

or ce n'est pas le cas ... enfin je ne peux pas l'affirmer

j'ai testé coté client et server dans les évènements on connect / on accept

- déjà pour un même client, le n°socket n'est pas le même coté client et server (mais bon c'est pas bien grave)

- après une dizaine de tentatives j'ai remarqué que plusieurs clients peuvent avoir le même n° socket (dans la partie client) pour moi ce n'est pas logique, ça sert à rien dans ce cas ...

mais là encore je m'en fou du coté client, c'est plutôt server qui m'intéresse

et avec une dizaines de tentative, je ne pense pas avoir eu le même n° socket client (partie server bien sur)

et donc je me demandais si comme dans la partie cliente, la partie server aura des doublons, ou est ce que ça continuera a générer des n° socket unique ?

j'ai testé socket car il me semblait être le plus logique vu qu'il apparait un peu partout ...

mais si on ne peut pas lui faire confiance (lol) je devrais changer, et utiliser soit le port local, ou le socket local, ou autre chose ?

doncon revient au départ, je cherche un n° unique à chaque client (généré par le server bien sur)

[LadyWasky]

ok je vais voir

mais n'oublie pas ce qu'il nous faut "un code unique qui est généré à la connexion et est retrouvé par le server à la déco"

Pas de soucis

En fait, l'idée est d'envoyer un tableau composé de :
- un identifiant (le pseudo du tchateur)
- Le message

donc on ne va pas passer par CLient.Write() et Serveur.Read(), mais par writebuf et Readbuf.

Ensuite, pour de la connection et la déconnection, effectivement, le socket "local" est un identifiant unique, pourquoi ?

En fait c'est tout couillon :
pour qu'une communication s'établisse en TCP/IP, il faut identifier la communication du processus client de façon unique, et pour ça, il y a plusieur niveau pour dire "c'est bien moi" :

1. L'adresse IP, qui identifie la machine qui communique.
   
2. Lle numéro de port, qui identifie le protocole utilisé (pour simplifier, on va l'assimiler au programme de tchat lui même)
   
3. Mais que se passe t'il, si sur la même machine, tu ouvre le même logiciel de tchat (donc tu as deux programmes qui tournent) et que tu les connecte au même serveur ? Il faut bien que le serveur réponde au bon client, non ?
   Hé bien, dans ce cas, il te faut un identifiant supplémentaire pour établir la communication : le socket local.
   Ce dernier est établi à la connection du client par le serveur, et comme tu l'as deviné, il est unique.
   Ce numéro est unique et ne fait que s'incrémenter à chaque nouvelle connection du serveur. C'est à dire que si un client se déconnecte, son numéro de socket ne sera jamais réattribué a une autre connection.

En attendant mieux, commences-tu a y voir clair avec ces explications ?

[Coussati]

bon avec le socket local, ça m'a l'air d'être bon

par contre j'aimerais parler d'une autre chose : en cas de reboot du pc, déconnexion internet ou autres ...

il me semble que l'évènement "on disconnect" n'est même pas déclencher; pire ! quand j'ai fais un test avec un pote et une demande du nbr client, il m'a donné 2 alors que mon pote c'était déconnecté d'internet

alors je voulais savoir quoi faire à ce moment là ? s'il y a qqchose de prévu ou ?

ou peut être chaque x minute (grâce à un timer) il y a une procédure de "refresh" ... ou ?

[LadyWasky]

Dans ce cas là, on en revient aux histoires de déconnexions sauvages (fil réseau débranché) dont on eu parlé il y a quelque temps.

C'est plus ou moins gérer par les pilotes et le système d'exploitation, et tu ne peux rien faire.

C'est un peut comme lorsque tu quites un site internet (un forum par exemple) sans t'être déconnecté et qu'au moment où tu reviens, il te dit que tu ne peux pas te loguer parce que la connexion est déjà établie.

Le serveur ne s'apercevra de la méprise que dans deux cas :
- lorsque l'OS lui aura dit
- lorsqu'il aura tenté d'envoyer des données au client.

Peut être peut tu résoudre ça en envoyant un message bidon à tous les clients supposés être connectés lorsque un nouveau client se connecte.

Quand je dis message, ça peut être par exemple une demande d'adresse IP avec la méthode PeerToAddress().

Comme la demande n'atteint jamais le client, une déconnexion est alors enfin déclenchée. (elle aurait pas pu venir toute seule te dis tu ? bin non.... )

C'est le genre de chose qui devrait être géré par les sous couches TCP/IP mais qui ne l'est pas. Du coup, côté applicatif, quand tu développes, tu t'arrache les cheveux de la tête, parce que tu n'as rien a ta disposition de vraiment fiable pour gérer ce genre de cas de figure.

C'est là où on s'aperçoit que l'informatique moderne à été un peu bâtie à la va-vite sur des fondations château-branlantes.

[Coussati]

ok ... dans ce cas j'avais préparé un autre pti module

déjà une question : pour déclencher une action toutes les x minutes, est ce qu'un timer est efficace ? ou il faut un thread et mettre un sleep() dans le thread ?

pour le moment comme je ne savais pas quoi faire j'utilise un timer : donc j'ai réglé sur 5 min

le server liste les socket locaux connecté et donc je compare la liste des joueurs en ligne et la liste des socket listé

je ne sais pas ce que ça va donné je vais testé

une dernière question : lors de la déco bourrin, un moment ou à un autre, l'os dira qu'un client s'est déconnecté, ou le socker server lui même en envoyant des données constatera une déconnexion ... je suppose bien que l'évènement "on disconect" sera déclenché ? ( et donc que j'aurai le n° socket local même avec un peu de retard)

[LadyWasky]

une dernière question : lors de la déco bourrin, un moment ou à un autre, l'os dira qu'un client s'est déconnecté, ou le socker server lui même en envoyant des données constatera une déconnexion ... je suppose bien que l'évènement "on disconect" sera déclenché ? ( et donc que j'aurai le n° socket local même avec un peu de retard)

Réponse : oui, mais par contre, au bout de combien de temps... ben, heu...

[Coussati]

et pour ma question à propos d'un test chaque x minutes ? le timer est suffisant ou un thread avec sleep() est meilleur ?

sachant que c'est une application, qui ne se ferme pas ...

[LadyWasky]

et pour ma question à propos d'un test chaque x minutes ? le timer est suffisant ou un thread avec sleep() est meilleur ?

sachant que c'est une application, qui ne se ferme pas ...

Je pense que le timer est suffisant
Un timer, ce n'est pas ça qui va casser les perfs de ton serveur.

[Coussati]

juste pour te remercier, c'est niquel comme ça