tu ne te connecte pas directement sur un poste d'un réseau....
se poste est connecté a un serveur, et tu contactes ensuite le client,
via son email ...
saisies tu la nuance ?
tu ne te connecte pas directement sur un poste d'un réseau....
se poste est connecté a un serveur, et tu contactes ensuite le client,
via son email ...
saisies tu la nuance ?
tu ne te connecte pas directement sur un poste d'un réseau....
se poste est connecté a un serveur, et tu contactes ensuite le client,
via son email ...
saisies tu la nuance ?
Salut RenField,
bah non, désolé !!
Si tu prends Yahoo messenger ou Msn Messenger, ils relient bien les 2
postes directement, non ?
Salut RenField,
bah non, désolé !!
Si tu prends Yahoo messenger ou Msn Messenger, ils relient bien les 2
postes directement, non ?
Salut RenField,
bah non, désolé !!
Si tu prends Yahoo messenger ou Msn Messenger, ils relient bien les 2
postes directement, non ?
"Eto Dermezel" a écrit dans le
message de news:Salut RenField,
bah non, désolé !!
Si tu prends Yahoo messenger ou Msn Messenger, ils relient bien les 2
postes directement, non ?
Hello,
Non, ils passent par un serveur. Sinon comment crois tu
que Yahoo Messenger pourrait afficher en jaune la petite
icone à coté de tes contacts connectés?
En plus, la plupart des gens ont des IP dynamiques, comment
feraient les clients pour "trouver" les autres clients?
Tout passe par un serveur centralisé, et alors c'est très simple:
Chaque client se fait connaitre (se connecte) au serveur (qui a
une IP fixe), et le serveur sert de passerelle entre les clients.
J'ai programmé un "Yahoo Messenger Light" en VB il y a quelque
temps, c'est tout facile avec le principe du serveur "au milieu"
et des clients en étoiles.
J'ai surement encore le code (serveur et clients), je mettrais ça
en ligne si ça intérèsse qqun.
"Eto Dermezel" <Stop_Laurent.bennabet@cegetel.net> a écrit dans le
message de news:mn.8c307d61ab4d691a.8309@cegetel.net...
Salut RenField,
bah non, désolé !!
Si tu prends Yahoo messenger ou Msn Messenger, ils relient bien les 2
postes directement, non ?
Hello,
Non, ils passent par un serveur. Sinon comment crois tu
que Yahoo Messenger pourrait afficher en jaune la petite
icone à coté de tes contacts connectés?
En plus, la plupart des gens ont des IP dynamiques, comment
feraient les clients pour "trouver" les autres clients?
Tout passe par un serveur centralisé, et alors c'est très simple:
Chaque client se fait connaitre (se connecte) au serveur (qui a
une IP fixe), et le serveur sert de passerelle entre les clients.
J'ai programmé un "Yahoo Messenger Light" en VB il y a quelque
temps, c'est tout facile avec le principe du serveur "au milieu"
et des clients en étoiles.
J'ai surement encore le code (serveur et clients), je mettrais ça
en ligne si ça intérèsse qqun.
"Eto Dermezel" a écrit dans le
message de news:Salut RenField,
bah non, désolé !!
Si tu prends Yahoo messenger ou Msn Messenger, ils relient bien les 2
postes directement, non ?
Hello,
Non, ils passent par un serveur. Sinon comment crois tu
que Yahoo Messenger pourrait afficher en jaune la petite
icone à coté de tes contacts connectés?
En plus, la plupart des gens ont des IP dynamiques, comment
feraient les clients pour "trouver" les autres clients?
Tout passe par un serveur centralisé, et alors c'est très simple:
Chaque client se fait connaitre (se connecte) au serveur (qui a
une IP fixe), et le serveur sert de passerelle entre les clients.
J'ai programmé un "Yahoo Messenger Light" en VB il y a quelque
temps, c'est tout facile avec le principe du serveur "au milieu"
et des clients en étoiles.
J'ai surement encore le code (serveur et clients), je mettrais ça
en ligne si ça intérèsse qqun.
"Eto Dermezel" wrote in message
news:Salut Jean-Marc,
Hello,Merci pour ces éclaicissements.
de rien :-)Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Oui, c'est eaxct, pour autant que je sache. Il y a bien une solution
pour établir vraiment une connection directe (après identification
auprès du serveur) , mais c'est un peu compliqué à expliquer ici,
et ça implique pas mal de prog en tout cas.
Donc je ne suis pas sur à 100% de la façon de procéder de Yahoo, mais
moi en tout cas je fais comme ça.Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
Je ne sais pas comment fait Yahoo exactement, mais je
suppose que c'est proche de cela, oui. En tout cas, moi
je fais comme ça.concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir
pas mal de connexions simultanées, cela passe toujours par un simple
composant winsock ???
On peut faire à base de Winsock ou d'API un serveur gérant "quelques"
connections simultanées (avec Rabbit, j'ai eu des pointes à 32
connections en réel, et j'ai fait des simulations jusqu'à 256).
Mon "Messenger Light" marchait avec juste Winsock, et ça allait
très bien, mais je n'ai jamais utilisé ça que pour discuter à
5 ou 6 machines, pas plus. Je suis à peu près certain que
ça marcherait avec une vingtaine de connections simultanées,
les machines modernes étant vraiment des monstres de puissance
en regard de la simplicité de la chose: échanger quelques caractères
ou des messages de quelques dizaines ou centaines de caractères
via TCP/IP, c'est minuscule comme travail. VB et Winsock
font ça très bien et très vite.
Evidemment, je ne ferais pas une implémentation
d'un VRAI serveur genre Messenger avec Winsock, et je ne le
ferais de toute façon pas en VB. Qui plus est, je ne le
ferais sans doute même pas sous Windows, sauf contraintes
particulières. La raison est que VB est très mal adapté
pour faire du multi-threading (il n'est d'ailleurs pas fait pour
ça), et qu'en plus Windows n'est pas le meilleur OS pour faire du
traitement massivement multi-thread.
Je ferais ça en C, sur un système Unix supportant les sockets berkeley,
et si j'ai le choix sur AIX.
Mais pour s'amuser ou pour des besoins légers, il n'y a aucun
problème. Comme ce type de messenger "perso" est en général
à accès limité, ça le fait très bien. En plus c'est rigolo comme
tout à faire :-))
"Eto Dermezel" <Stop_Laurent.bennabet@cegetel.net> wrote in message
news:mn.923a7d61a4d9921e.8309@cegetel.net...
Salut Jean-Marc,
Hello,
Merci pour ces éclaicissements.
de rien :-)
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Oui, c'est eaxct, pour autant que je sache. Il y a bien une solution
pour établir vraiment une connection directe (après identification
auprès du serveur) , mais c'est un peu compliqué à expliquer ici,
et ça implique pas mal de prog en tout cas.
Donc je ne suis pas sur à 100% de la façon de procéder de Yahoo, mais
moi en tout cas je fais comme ça.
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
Je ne sais pas comment fait Yahoo exactement, mais je
suppose que c'est proche de cela, oui. En tout cas, moi
je fais comme ça.
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir
pas mal de connexions simultanées, cela passe toujours par un simple
composant winsock ???
On peut faire à base de Winsock ou d'API un serveur gérant "quelques"
connections simultanées (avec Rabbit, j'ai eu des pointes à 32
connections en réel, et j'ai fait des simulations jusqu'à 256).
Mon "Messenger Light" marchait avec juste Winsock, et ça allait
très bien, mais je n'ai jamais utilisé ça que pour discuter à
5 ou 6 machines, pas plus. Je suis à peu près certain que
ça marcherait avec une vingtaine de connections simultanées,
les machines modernes étant vraiment des monstres de puissance
en regard de la simplicité de la chose: échanger quelques caractères
ou des messages de quelques dizaines ou centaines de caractères
via TCP/IP, c'est minuscule comme travail. VB et Winsock
font ça très bien et très vite.
Evidemment, je ne ferais pas une implémentation
d'un VRAI serveur genre Messenger avec Winsock, et je ne le
ferais de toute façon pas en VB. Qui plus est, je ne le
ferais sans doute même pas sous Windows, sauf contraintes
particulières. La raison est que VB est très mal adapté
pour faire du multi-threading (il n'est d'ailleurs pas fait pour
ça), et qu'en plus Windows n'est pas le meilleur OS pour faire du
traitement massivement multi-thread.
Je ferais ça en C, sur un système Unix supportant les sockets berkeley,
et si j'ai le choix sur AIX.
Mais pour s'amuser ou pour des besoins légers, il n'y a aucun
problème. Comme ce type de messenger "perso" est en général
à accès limité, ça le fait très bien. En plus c'est rigolo comme
tout à faire :-))
"Eto Dermezel" wrote in message
news:Salut Jean-Marc,
Hello,Merci pour ces éclaicissements.
de rien :-)Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Oui, c'est eaxct, pour autant que je sache. Il y a bien une solution
pour établir vraiment une connection directe (après identification
auprès du serveur) , mais c'est un peu compliqué à expliquer ici,
et ça implique pas mal de prog en tout cas.
Donc je ne suis pas sur à 100% de la façon de procéder de Yahoo, mais
moi en tout cas je fais comme ça.Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
Je ne sais pas comment fait Yahoo exactement, mais je
suppose que c'est proche de cela, oui. En tout cas, moi
je fais comme ça.concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir
pas mal de connexions simultanées, cela passe toujours par un simple
composant winsock ???
On peut faire à base de Winsock ou d'API un serveur gérant "quelques"
connections simultanées (avec Rabbit, j'ai eu des pointes à 32
connections en réel, et j'ai fait des simulations jusqu'à 256).
Mon "Messenger Light" marchait avec juste Winsock, et ça allait
très bien, mais je n'ai jamais utilisé ça que pour discuter à
5 ou 6 machines, pas plus. Je suis à peu près certain que
ça marcherait avec une vingtaine de connections simultanées,
les machines modernes étant vraiment des monstres de puissance
en regard de la simplicité de la chose: échanger quelques caractères
ou des messages de quelques dizaines ou centaines de caractères
via TCP/IP, c'est minuscule comme travail. VB et Winsock
font ça très bien et très vite.
Evidemment, je ne ferais pas une implémentation
d'un VRAI serveur genre Messenger avec Winsock, et je ne le
ferais de toute façon pas en VB. Qui plus est, je ne le
ferais sans doute même pas sous Windows, sauf contraintes
particulières. La raison est que VB est très mal adapté
pour faire du multi-threading (il n'est d'ailleurs pas fait pour
ça), et qu'en plus Windows n'est pas le meilleur OS pour faire du
traitement massivement multi-thread.
Je ferais ça en C, sur un système Unix supportant les sockets berkeley,
et si j'ai le choix sur AIX.
Mais pour s'amuser ou pour des besoins légers, il n'y a aucun
problème. Comme ce type de messenger "perso" est en général
à accès limité, ça le fait très bien. En plus c'est rigolo comme
tout à faire :-))
Salut Jean-Marc,
Merci pour ces éclaicissements.
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir
pas mal de connexions simultanées, cela passe toujours par un simple
composant winsock ???
Salut Jean-Marc,
Merci pour ces éclaicissements.
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir
pas mal de connexions simultanées, cela passe toujours par un simple
composant winsock ???
Salut Jean-Marc,
Merci pour ces éclaicissements.
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir
pas mal de connexions simultanées, cela passe toujours par un simple
composant winsock ???
Salut Jean-Marc,
Merci pour ces éclaicissements.
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir
pas mal de connexions simultanées, cela passe toujours par un simple
composant winsock ???
Eto
Salut Jean-Marc,
Merci pour ces éclaicissements.
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir
pas mal de connexions simultanées, cela passe toujours par un simple
composant winsock ???
Eto
Salut Jean-Marc,
Merci pour ces éclaicissements.
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir
pas mal de connexions simultanées, cela passe toujours par un simple
composant winsock ???
Eto
Eto Dermezel a écrit :Salut Jean-Marc,
Merci pour ces éclaicissements.
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir pas
mal de connexions simultanées, cela passe toujours par un simple composant
winsock ???
Eto
Pas forcement.
Tu peux imaginer que le serveur ne se charge que de mettre en relation les
différents clients, mais que les communications entre les clients soient
directes. Cela permet de liberer de la bande passante au niveau du serveur.
Vincent Guichard
Eto Dermezel a écrit :
Salut Jean-Marc,
Merci pour ces éclaicissements.
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir pas
mal de connexions simultanées, cela passe toujours par un simple composant
winsock ???
Eto
Pas forcement.
Tu peux imaginer que le serveur ne se charge que de mettre en relation les
différents clients, mais que les communications entre les clients soient
directes. Cela permet de liberer de la bande passante au niveau du serveur.
Vincent Guichard
Eto Dermezel a écrit :Salut Jean-Marc,
Merci pour ces éclaicissements.
Par contre, du coup, cela revèle des nouvelles questions !
Si j'ai bien compris le schéma :
Client1 appelle le serveur en spécifiant qui il doit contacter
Serveur accepte la connexion
Serveur se connecte lui même sur client2
A aucun moment, Client1 et Client2 sont connectés ensembles, c'est ça ?
Si on transfert un fichier de client1 à client2
Client1 envoie le fichier au serveur
le serveur envoie le fichier au client2 ?
concernant le serveur, cela sous-entend qu'il puisse gérer et maintenir pas
mal de connexions simultanées, cela passe toujours par un simple composant
winsock ???
Eto
Pas forcement.
Tu peux imaginer que le serveur ne se charge que de mettre en relation les
différents clients, mais que les communications entre les clients soient
directes. Cela permet de liberer de la bande passante au niveau du serveur.
Vincent Guichard
Salut Vincent,
oki, je préfèrerais aussi, mais :
Client1 appelle Serveur
Serveur appelle Client 2
comment mettre en relation client1 et client2 de manière directe ?
Salut Vincent,
oki, je préfèrerais aussi, mais :
Client1 appelle Serveur
Serveur appelle Client 2
comment mettre en relation client1 et client2 de manière directe ?
Salut Vincent,
oki, je préfèrerais aussi, mais :
Client1 appelle Serveur
Serveur appelle Client 2
comment mettre en relation client1 et client2 de manière directe ?
"Eto Dermezel" a écrit dans le
message de news:Salut Vincent,
oki, je préfèrerais aussi, mais :
Client1 appelle Serveur
Serveur appelle Client 2
comment mettre en relation client1 et client2 de manière directe ?
Hello,
ce n'est pas compliqué, mais ça demande un peu de gymnastique
intellectuelle pour suivre l'explication.
0/ Le serveur est lancé, il écoute sur un port, par exemple
le port 1234
"Client1" et "Client2" sont des usagers du Serveur. Il les
connait par leurs noms.
1/ Client 1 se connecte au serveur (port 1234) et le serveur
accpepte la connection (il ouvre donc pour cela un socket
client et la communication est établie.
A ce moment, Serveur connait IP1 (l'IP du client 1)
2/ CLient 2 se connecte, comme le client 1
Même conclusion, Seveur Connait maintenant IP2 (IP client 2)
Le serveur garde donc qq part l'information:
"Client 1" => IP1
"Client 2" => IP2
3/ Client 1 souhaite établir un dialogue avec Client 2. Il en informe
le serveur, en envoyant un message au Serveur, en lui disant par
exemple <DEMANDE CONNECTION 'Client 2'>
4/ Le serveur s'assure que client 2 est bien la, puis il fait ceci:
a) envoie un message à CLient 2 lui disant:
<OUVRE UN PORT EN ECOUTE ET DIS MOI QUEL PORT, MERCI!>
b) CLient 2 reçoit, accepte, ouvre un port en listen (par exemple
2345) et prévient Serveur que c'est fait:
<OK, J AI OUVERT LE PORT 2345>
c) Serveur envoie un message à client 1:
<OK POUR TA CONNECTION AVEC CLIENT 2, VOICI LES INFOS
IP = IP2 (l'adresse IP de client 2)
PORT#45>
d) Client 1 reçoit les infos, et demande une connection à l'adresse
IP2, port 2345
e) CLient 2 accepte sur un nouveau socket client et le channel est
établi entre Client 2 et CLient 1 et le tour est joué.
Bien sur, clients et serveur gardent ouvertes leurs connections
Clients/Serveurs, mais cette connection n'est utilisée que pour
échanger des messages de services, du genre: qui est connecté,
si un autre client comme CLient 3 demande à parler à CLient 1, etc.
Pas compliqué à implémenter, et ce de façon très simple avec quelques
Winsock.
Les échanges clients/Serveurs se limitant aux échanges de service, c'est
super light pour le serveur. Il doit juste garder plein de sockets
clients ouverts pour les services, mais avec très peu de traffic.
L'astuce, c'est que les clients (ils sont clients par rapport au
serveur)
peuvent à un instant donné (établissement d'une connnection directe avec
un autre client) se comporter comme un serveur, juste le temps
d'accepter
la connection du partenaire sur un nouveau socket client.
Un client a donc:
- un socket CLIENT, réservé à la communication avec le serveur
Celui ci existe du début de la connection au serveur jusqu'à
la fermeture de l'application par l'utilisateur de CLient 1
- un socket SERVEUR, pour l'établissement de connections clientes
directes avec un autre client (juste le temps du ACCEPT)
- un à n sockets Clients (dynamiques c'est le mieux, c'est à
dire chargés par un Load ), pour les connections directes
client(s)/client(s)
Avec ce principe, tu peux avoir N clients connectés à P autres
clients, sans que le serveur soit dérangé. Il les a juste aidé
à se connaitre les uns les autres par leurs IP et il ne fait que
maintenir la petite table : NOM CLIENT <=> IP, et relayer
les messages de services.
C'est tout simple une fois qu'on a le principe.
A toi d'imaginer un petit protocole d'échange pour les messages
entre les clients et le serveur, le serveur et les clients et
les clients entre eux.
Avec une dizaine de messages et de réponses, tu as fait le tour
des fonctionnalités offertes par ce genre de messagers:
- qui est connecté
- qui se connecte/déconnecte (toc toc toc :-)) )
- gestion des amis, des bannis, etc.
- petite figure qui clignote quand l'autre tapote
- transfert de fichiers
- conférence à plusieurs
En fait, la programmation "technique" (les sockets et tout ça) est
vraiment simple (il n' y a pas de piège, c'est à la portée d'un bon
élèvre de premiere année d'étude d'info) MAIS ce qui est hyper
pénible à faire (pas dur, hein, PENIBLE) c'est toute la gestion
graphique des interfaces clients, si tu veux que ce soit joli.
"Eto Dermezel" <Stop_Laurent.bennabet@cegetel.net> a écrit dans le
message de news:mn.93e17d617b0c80e8.8309@cegetel.net...
Salut Vincent,
oki, je préfèrerais aussi, mais :
Client1 appelle Serveur
Serveur appelle Client 2
comment mettre en relation client1 et client2 de manière directe ?
Hello,
ce n'est pas compliqué, mais ça demande un peu de gymnastique
intellectuelle pour suivre l'explication.
0/ Le serveur est lancé, il écoute sur un port, par exemple
le port 1234
"Client1" et "Client2" sont des usagers du Serveur. Il les
connait par leurs noms.
1/ Client 1 se connecte au serveur (port 1234) et le serveur
accpepte la connection (il ouvre donc pour cela un socket
client et la communication est établie.
A ce moment, Serveur connait IP1 (l'IP du client 1)
2/ CLient 2 se connecte, comme le client 1
Même conclusion, Seveur Connait maintenant IP2 (IP client 2)
Le serveur garde donc qq part l'information:
"Client 1" => IP1
"Client 2" => IP2
3/ Client 1 souhaite établir un dialogue avec Client 2. Il en informe
le serveur, en envoyant un message au Serveur, en lui disant par
exemple <DEMANDE CONNECTION 'Client 2'>
4/ Le serveur s'assure que client 2 est bien la, puis il fait ceci:
a) envoie un message à CLient 2 lui disant:
<OUVRE UN PORT EN ECOUTE ET DIS MOI QUEL PORT, MERCI!>
b) CLient 2 reçoit, accepte, ouvre un port en listen (par exemple
2345) et prévient Serveur que c'est fait:
<OK, J AI OUVERT LE PORT 2345>
c) Serveur envoie un message à client 1:
<OK POUR TA CONNECTION AVEC CLIENT 2, VOICI LES INFOS
IP = IP2 (l'adresse IP de client 2)
PORT#45>
d) Client 1 reçoit les infos, et demande une connection à l'adresse
IP2, port 2345
e) CLient 2 accepte sur un nouveau socket client et le channel est
établi entre Client 2 et CLient 1 et le tour est joué.
Bien sur, clients et serveur gardent ouvertes leurs connections
Clients/Serveurs, mais cette connection n'est utilisée que pour
échanger des messages de services, du genre: qui est connecté,
si un autre client comme CLient 3 demande à parler à CLient 1, etc.
Pas compliqué à implémenter, et ce de façon très simple avec quelques
Winsock.
Les échanges clients/Serveurs se limitant aux échanges de service, c'est
super light pour le serveur. Il doit juste garder plein de sockets
clients ouverts pour les services, mais avec très peu de traffic.
L'astuce, c'est que les clients (ils sont clients par rapport au
serveur)
peuvent à un instant donné (établissement d'une connnection directe avec
un autre client) se comporter comme un serveur, juste le temps
d'accepter
la connection du partenaire sur un nouveau socket client.
Un client a donc:
- un socket CLIENT, réservé à la communication avec le serveur
Celui ci existe du début de la connection au serveur jusqu'à
la fermeture de l'application par l'utilisateur de CLient 1
- un socket SERVEUR, pour l'établissement de connections clientes
directes avec un autre client (juste le temps du ACCEPT)
- un à n sockets Clients (dynamiques c'est le mieux, c'est à
dire chargés par un Load ), pour les connections directes
client(s)/client(s)
Avec ce principe, tu peux avoir N clients connectés à P autres
clients, sans que le serveur soit dérangé. Il les a juste aidé
à se connaitre les uns les autres par leurs IP et il ne fait que
maintenir la petite table : NOM CLIENT <=> IP, et relayer
les messages de services.
C'est tout simple une fois qu'on a le principe.
A toi d'imaginer un petit protocole d'échange pour les messages
entre les clients et le serveur, le serveur et les clients et
les clients entre eux.
Avec une dizaine de messages et de réponses, tu as fait le tour
des fonctionnalités offertes par ce genre de messagers:
- qui est connecté
- qui se connecte/déconnecte (toc toc toc :-)) )
- gestion des amis, des bannis, etc.
- petite figure qui clignote quand l'autre tapote
- transfert de fichiers
- conférence à plusieurs
En fait, la programmation "technique" (les sockets et tout ça) est
vraiment simple (il n' y a pas de piège, c'est à la portée d'un bon
élèvre de premiere année d'étude d'info) MAIS ce qui est hyper
pénible à faire (pas dur, hein, PENIBLE) c'est toute la gestion
graphique des interfaces clients, si tu veux que ce soit joli.
"Eto Dermezel" a écrit dans le
message de news:Salut Vincent,
oki, je préfèrerais aussi, mais :
Client1 appelle Serveur
Serveur appelle Client 2
comment mettre en relation client1 et client2 de manière directe ?
Hello,
ce n'est pas compliqué, mais ça demande un peu de gymnastique
intellectuelle pour suivre l'explication.
0/ Le serveur est lancé, il écoute sur un port, par exemple
le port 1234
"Client1" et "Client2" sont des usagers du Serveur. Il les
connait par leurs noms.
1/ Client 1 se connecte au serveur (port 1234) et le serveur
accpepte la connection (il ouvre donc pour cela un socket
client et la communication est établie.
A ce moment, Serveur connait IP1 (l'IP du client 1)
2/ CLient 2 se connecte, comme le client 1
Même conclusion, Seveur Connait maintenant IP2 (IP client 2)
Le serveur garde donc qq part l'information:
"Client 1" => IP1
"Client 2" => IP2
3/ Client 1 souhaite établir un dialogue avec Client 2. Il en informe
le serveur, en envoyant un message au Serveur, en lui disant par
exemple <DEMANDE CONNECTION 'Client 2'>
4/ Le serveur s'assure que client 2 est bien la, puis il fait ceci:
a) envoie un message à CLient 2 lui disant:
<OUVRE UN PORT EN ECOUTE ET DIS MOI QUEL PORT, MERCI!>
b) CLient 2 reçoit, accepte, ouvre un port en listen (par exemple
2345) et prévient Serveur que c'est fait:
<OK, J AI OUVERT LE PORT 2345>
c) Serveur envoie un message à client 1:
<OK POUR TA CONNECTION AVEC CLIENT 2, VOICI LES INFOS
IP = IP2 (l'adresse IP de client 2)
PORT#45>
d) Client 1 reçoit les infos, et demande une connection à l'adresse
IP2, port 2345
e) CLient 2 accepte sur un nouveau socket client et le channel est
établi entre Client 2 et CLient 1 et le tour est joué.
Bien sur, clients et serveur gardent ouvertes leurs connections
Clients/Serveurs, mais cette connection n'est utilisée que pour
échanger des messages de services, du genre: qui est connecté,
si un autre client comme CLient 3 demande à parler à CLient 1, etc.
Pas compliqué à implémenter, et ce de façon très simple avec quelques
Winsock.
Les échanges clients/Serveurs se limitant aux échanges de service, c'est
super light pour le serveur. Il doit juste garder plein de sockets
clients ouverts pour les services, mais avec très peu de traffic.
L'astuce, c'est que les clients (ils sont clients par rapport au
serveur)
peuvent à un instant donné (établissement d'une connnection directe avec
un autre client) se comporter comme un serveur, juste le temps
d'accepter
la connection du partenaire sur un nouveau socket client.
Un client a donc:
- un socket CLIENT, réservé à la communication avec le serveur
Celui ci existe du début de la connection au serveur jusqu'à
la fermeture de l'application par l'utilisateur de CLient 1
- un socket SERVEUR, pour l'établissement de connections clientes
directes avec un autre client (juste le temps du ACCEPT)
- un à n sockets Clients (dynamiques c'est le mieux, c'est à
dire chargés par un Load ), pour les connections directes
client(s)/client(s)
Avec ce principe, tu peux avoir N clients connectés à P autres
clients, sans que le serveur soit dérangé. Il les a juste aidé
à se connaitre les uns les autres par leurs IP et il ne fait que
maintenir la petite table : NOM CLIENT <=> IP, et relayer
les messages de services.
C'est tout simple une fois qu'on a le principe.
A toi d'imaginer un petit protocole d'échange pour les messages
entre les clients et le serveur, le serveur et les clients et
les clients entre eux.
Avec une dizaine de messages et de réponses, tu as fait le tour
des fonctionnalités offertes par ce genre de messagers:
- qui est connecté
- qui se connecte/déconnecte (toc toc toc :-)) )
- gestion des amis, des bannis, etc.
- petite figure qui clignote quand l'autre tapote
- transfert de fichiers
- conférence à plusieurs
En fait, la programmation "technique" (les sockets et tout ça) est
vraiment simple (il n' y a pas de piège, c'est à la portée d'un bon
élèvre de premiere année d'étude d'info) MAIS ce qui est hyper
pénible à faire (pas dur, hein, PENIBLE) c'est toute la gestion
graphique des interfaces clients, si tu veux que ce soit joli.
