Discussion :

[spikto]

Bonjour j'ai un serveur tcp indy sur un form et je voudrais envoyer un message à l'aide du bouton mais la commande "AThread.Connection.Writeln('');" ne marche pas dans le bouton, ce qui est logique puisque le bouton est un Sender: TObject tandis que la commande à besoin de sa AThread:TIdPeerThread alors je voudrais savoir comment faire pour envoyer un message au client ?

Merci d'avance

[Reisubar]

Il faut effectuer la manip dans la procédure d'évènement OnExecute (CF FAQ Indy de ce site).

[spikto]

Non car je désire que le serveur puisse parler avec les clients donc sa ne peut pas être dans on execute

[Reisubar]

je désire que le serveur puisse parler avec les clients

Un serveur ne "parle" pas aux clients, il leur réponds. Et c'est bien dans ce gestionnaire d'évènement que tu dois effectuer ce dialogue.

[spikto]

Dans mon cas on peut dire que oui car le serveur est celui qui heberge la partie donc le serveur peut parler au client.
Alors comment puis-je faire executer mon bouton dans Onexecute puisque a parament on ne peut pas le faire dans la procédure du bouton.

[Reisubar]

Dans mon cas on peut dire que oui car le serveur est celui qui heberge la partie donc le serveur peut parler au client.

Non, un serveur ne peut pas parler à un client. Un serveur ne peut que répondre à une demande initiée par un client, ou bien alors il n'est plus serveur. Les requêtes client étant reçues dans l'évènement OnExecute, cela n'a pas de sens de demander une écriture ailleurs comme dans un gestionnaire d'évènement lié à un bouton (ton cas).

J'ai l'impression que ton architecture a été inversée. Si le serveur doit s'adresser au client, les clients doivent être serveurs et inversement, ou doivent implémenter un serveur. A moins que tu aie conçu ton protocole pour que les clients "bloquent" sur un ReadLn(), que le serveur "débloque" en renvoyant à un certain moment une valeur... Est-ce le cas ?...

[spikto]

Voila exactement ce que je souhaite faire :
Dans une même application je veut que une personne puisse heberger une partie (donc j'ai penser au serveur) et que un client puisse le rejoindre (donc j'ai pensée à client).
Donc si tu as une idée de stucture je suis pret à l'entendre.

[spikto]

Rien à me proposer

J'ai penser alors que le serveur gere les parties c'est à dire que les joueurs doivent crée une partie sur le serveur ?
A ce moment là comment faire ?

[Reisubar]

Il en effet judicieux que le serveur fasse tout, les parties étant entièrement gérées par lui. Le problème que tu peut avoir est le suivant : comment le serveur peut il envoyer des infos aux clients alors qu'ils n'ont rien demandé (ce qui est théoriquement illogique de la part d'un serveur, mais dans ton cas peut être nécessaire)

Une piste est la suivante : chaque client crée un thread auxiliaire qui se connecte au serveur et s'identifie comme thread particulier. Ensuite, il fait un ReadLn, ou tout du moins quielque chose de bloquant (Read quelque chose).
Côté serveur, la détection se fait au niveau de OnExecute, et ce thread est "rerouté" vers une fonction quelconque qui par défaut ne renvoie rien. Par conséquent, ce thread particulier est bloqué en attente de données.

Lorsque tu veux envoyer un message au client, il te suffit dans la fonction qui tout à l'heure ne renvoyait rien, de justement cette fois ci envoyer des données. Ceci débloquera le client qui les recevra. L'envoi peut être initié par un TEvent : chaque client en possède un, l'entrée dans la fonction particulière appelle TEvent.WaitFor. Lorsqu'un message a besoin d'être délivré, (depuis un bouton, si tu le souhaites !), tu débloques cet évènement via MyEvent.Signal... Alors il y a lecture des données et renvoi au client.

C'est une idée que j'avais déjà développé ici :
http://groups.google.com/group/borland.public.delphi.internet.winsock/browse_thread/thread/fda7fa08539dc6b2/7ae8e26e88de466d?lnk=st&rnum=1&hl=fr#7ae8e26e88de466d

Bon courage !