En fait j'ai un prog style chat en c++ et je voudrais afficher la liste des personnes connectes sous ce prog... le probleme c comment le faire parce que en reseau local, avec une adresse broadcast ca doit marcher, mais sur internet???
 
Est ce quelqu'un s'y connait un peu sachant que j'utilise le tcp/ip avec les sockets windows pour la connection....???

Personne a une petite idee???    

billyboy78 a écrit a écrit : Personne a une petite idee???

 
pô moi en tout cas  

 
Bin ton serveur il fait du processing de clients non. Il a donc l'info. Il suffit qu'il la mette à disposition du client ...

juju_le_barbare a écrit a écrit :     pô moi en tout cas

 
Merci de ta participation somme toute inutile mais tout de meme sympatique  

 
Je n'est pas de serveur, la connection se fait uniquement entre 2 personnes, aucun serveur entre les 2...

 
Liste des personnes connectes sous ce prog = toi et l'autre gars
 
Comprends pas ta question ....

darklord22 a écrit a écrit :     Liste des personnes connectes sous ce prog = toi et l'autre gars   Comprends pas ta question ....

 
Bah non justement, quand je me connecte pour chatter par exemple, ok c avec un autre gars, mais disons qu'a un moment donne il y ait 10 personnes qui ait ouvert le logiciel, et que moi je souhaite avoir la liste des c 10 personnes pour choisir avec laquelle je veux me connecter, (en gros je veux recuperer l'ip) comment je fais???

pas de miracle, faut une machine qui joue le rôle de serveur.

 
bah moi ca me semblerait logique aussi... mais ce qui me trouble c ca...
 
A une epoque j'avais fais un programme de chat comme ca avec directplay,  et il y a une fonction qui permet d'interroger le reseau (intranet ou internet, j'ai teste) et renvoyais l'ip d'une autre personne qui avais le programme de chat, alors comment cette fonction fait-elle pour retrouver ca?

aucune idée ton truc me rappelle que doom marchait déjà comme ça, et que quake peut trouver un réseau local.
 
si tu ne trouves rien, les sources de quake2 sont dispos > bonne recherche.

te casse pas la tete et fais un serveur central. Tu peux faire tourner ca sur une machine isolée. Ca bouffe rien comme BP / CPU Et c'est bcp plus efficace que de scanner tout le réseau chaque fois que qqun demande la liste ...

 
 
ouais masis bon je trouve ca dommage de perdre du tps a faire un prog serveur qui ne fait que maintenir la liste des personnes, alors que c possible puisque que ca marche en directplay... mais avec les sockets windows, la mystere

Si quelqu'un d'autre peu eclairer ma lanterne, je reste ouvert a toutes suggestions....

billyboy78 a écrit a écrit : Si quelqu'un d'autre peu eclairer ma lanterne, je reste ouvert a toutes suggestions....

 
Bah ton client peut écouter sur un port donné, genre 7111. Lorsqu'un process ouvre une connec sur le port 7111, il renvoie une chain de caractère avec l'info souhaitée (nom par exemple)
 
Ainsi, ton client scanne les ips de ton intranet et si le port 7111 répond c'est bon.
 
Mais crois moi c'est une perte de bp et c'est pas performant du tout!

 
ouais ca on est d'accord, cote performance c pas gagne, par contre a ton avis, ce type de systeme ca peut aussi marcher sur internet....?
 
Car comme pour auparavant, avec directplay je retrouvais une personne en moins de 5 secondes sur internet

ah ah ah ah ah ah ah  
 
Et tu fais comment pour scanner toutes les ip d'internet? Une à une en 5 secondes ?
 
Ton directplay, tu sais cmt ca marche? Moi je te parie tout ce que tu veux qu'il y un serveur central derrière. De toutes façons le broadcast, c'est théorique sur l'internet public ... Si tu crois que ce genre de truc est supporté par tous les FAI ...
 
Bref, arrête de rêver et renseigne toi sur ton prog directplay. Il doit y avoir un serveur central ou du moins un ensemble de nodes connectés entre eux  
 
 

darklord22 a écrit a écrit : ah ah ah ah ah ah ah     Et tu fais comment pour scanner toutes les ip d'internet? Une à une en 5 secondes ?   Ton directplay, tu sais cmt ca marche? Moi je te parie tout ce que tu veux qu'il y un serveur central derrière. De toutes façons le broadcast, c'est théorique sur l'internet public ... Si tu crois que ce genre de truc est supporté par tous les FAI ...   Bref, arrête de rêver et renseigne toi sur ton prog directplay. Il doit y avoir un serveur central ou du moins un ensemble de nodes connectés entre eux

 
c bien ce que je te dis, ca me semble plus que bizarre....
mais y'a pas de serveur derriere.. c moi qui l'avais fait a partie d'un de leur exemples, enfin bon peu importe, je vais voir, merci pour l'aide

[edtdd]--Message édité par billyboy78--[/edtdd]

ok no prob ...

Et à propos d'UDP ?
Winsock permet d'utiliser UDP, et il me semble qu'il est indiqué dans ton cas, bien que je ne sais pas trop ce que c'est
Quake justement utilise UDP ... petetre un signe ...
 
http://perso.libertysurf.fr/rollin [...] cp-udp.htm
 
"UDP est utile pour des applications orientées commande/réponse dont les données tiennent dans un seul datagramme. Ce protocole est moins lourd que TCP car il ne nécessite pas d'ouverture, de maintien et de fermeture de connexion, ce qui en fait aussi un protocole plus rapide, plus simple mais moins robuste, moins sécurisé.
UDP est aussi très pratique pour ce qui est diffusion ou multidiffusion (broadcast); imaginer se connecter à 1000 machines pour un broadcast !!!"
 
t'envoit un datagramme "si vous etes en train de chatter, répondez"
et cote client quand tu recoit ce datagremme, tu répond "moi je chat, voila mon nom et mon ip"
 
je crois que ca fonctionne comme ca ...

HelloWorld a écrit a écrit : Et à propos d'UDP ? Winsock permet d'utiliser UDP, et il me semble qu'il est indiqué dans ton cas, bien que je ne sais pas trop ce que c'est Quake justement utilise UDP ... petetre un signe ...   http://perso.libertysurf.fr/rollin [...] cp-udp.htm   "UDP est utile pour des applications orientées commande/réponse dont les données tiennent dans un seul datagramme. Ce protocole est moins lourd que TCP car il ne nécessite pas d'ouverture, de maintien et de fermeture de connexion, ce qui en fait aussi un protocole plus rapide, plus simple mais moins robuste, moins sécurisé. UDP est aussi très pratique pour ce qui est diffusion ou multidiffusion (broadcast); imaginer se connecter à 1000 machines pour un broadcast !!!"   t'envoit un datagramme "si vous etes en train de chatter, répondez" et cote client quand tu recoit ce datagremme, tu répond "moi je chat, voila mon nom et mon ip"   je crois que ca fonctionne comme ca ...

 
 
mmm oui ca se pourrais bien etre une pas mauvaise idee, la par contre, ca va etre cho pour moi, il va falloir que je regarde ca de plus pres, parce que a par ce que j'ai pu en voir en cours, c a dire pas grand chose, il faut que je capte commment ca marche et comment le mettre en oeuvre.
 
En tout cas merci pour l'idee, ca peut peut etre bien marcher..

Le broadcast c'est théorique. Rare sont les FAIs qui le supporte. En tout cas, à un niveau public international, certainement pas. Ici, il s'agit de déterminer quels sont les clients connectés. UDP ou TCP ne rentre pas en ligne de compte.
 
UDP est plus utilie pour des applications orientées streaming, voix, media, etc. Car il n'a pas la qualité de service (et donc la latency) de TCP.  
 
Tu ne voudrais pas que lorsque tu tapes un message à ton correspondant, il n'aparaisse pas? Avec UDP, si tu perds un packet dans un routeur, rien ne sera entrepris pour corriger le problème (e.g. renvoyer le packet).  
 
Bref, tout ca pour dire qu'à un niveau intranet limité c'est faisable mais certainement pas au niveau internet international. Pas mal de recherches sont en cours sur le multicast et son support avec de la QoS mais ne rêve pas ... C'est pas demain la veille  
 
A+

je dis donc: serveur central ou du moins un ensemble de nodes qui parle entre eux. Tu vas perdre plus de temps à trouver un machin qui marchera jamais plutot que de coder un petit serveur d'enregistrement. Ca prend meme pas 1j si tu as un protocole simple.
 
A+

 
Donc tu envoie un datagramme en broadcast à toute les machines connectées à Internet ???
 
Allez sérieusement ca te parait faisable ca ?
 
ah la la
 
Et je me répète: que ce soit UDP ou TCP n'a rien à voir là dedans ...