Discussion :

[billynirvana]

Bonjour,

Je souhaite mettre en place une application Client / Serveur en JAVA avec les particularités suivantes:
1- Le serveur accepte N clients.
2- Chaque client envoie des données au serveur.
3- Le serveur fait un traitement des valeurs récupérées de ces clients. nb: vérification que chaque client a envoyé la requete.
4- Renvoie des données à chaque client. Les données envoyées sont identiques pour chaque client.

J'ai posté dans ce sous-forum car cela s'apprete presque à un modèle de jeu video en réseau.


Quelle structure utilisez vous dans le monde du jeu vidéo pour réaliser un truc de ce genre?

NB: J'ai déjà pensé à du broadcast pour l'envoi des données du serveur au N clients (4-).

Merci pour vos aides et précisions.


Cdlt,

Kurt-Kobain

[Ti-R]

Cela dépend !

C'est possible en UDP/TCP ce que tu demandes.

2 exemples:
Mais si c'est pour diffuser de la vidéo sur n clients -> UDP.
Si c'est du transfert de fichiers -> TCP

Donc au final c'est pour faire quoi ?

[billynirvana]

C'est un peu bizarre. Chaque poste client fait du "monitoring" d'un parametre sur son poste.
Le serveur recoit les différentes réponse des clients. Il fait la tambouille et renvoie aux différents clients les résultats.

Chaque client affiche l'intégralité du monitoring.


Il n'y a pas aucun fichiers de transferer, juste des bytes (ou kbytes)


Je trouve que cela ressemble pas mal à des jeux vidéos style warcraft ou autres...

[Ti-R]

En TCP cela va être plus simple dans ton cas !

Ensuite c'est comme tu as indiqué, envoie du client, réception du serveur, traitement, et renvoie d'information vers le client sur le même socket.

[billynirvana]

OK! Mais concernant les problèmes de synchronisation. Comment j'opère?

Comment vérifier que chaque client a bien envoyé la réponse?
Et pour les lags (meme si c'est pas très grave hein!) comment les diminuer?


Un Grand Merci pour tes réponses!



Billy

[Ti-R]

Je ne vois pas les problèmes de synchronisation ?

Le serveur peut renvoyer l'information traité vers tous les clients connectés.
Pour diminuer les lags ce n’est pas facile, avoir une bonne connexion côté serveur, et ne pas monopoliser 100% du CPU côté serveur.

[billynirvana]

Pbs de synchronisation: Instant T dans mon graphe: Il me faut les N valeurs. Donc avant de renvoyer les résultats, je dois récupérer les N valeurs, ensuite envoyer en broadcast le résultat.

Imagine qu'un pc mette du temps, je dois donc faire "laguer" tous les autres... et imagine qu'il a planté!

Si je peux m'exprimer ainsi...

Comment dois je m'y prendre? Existe il un timeout de réception des messages?

[Ti-R]

Un client n1 envoie un message vers le serveur (le message est envoyé à n2 qui est connecté)
10s plus tard un autre client n2 envoie un message vers le serveur (le message est envoyé à n1)

Toutes les secondes n1 et n2 affiches les données, qui sont forcément décalé dans le temps, vu que l'échange d'information se fait à une vitesse donné.

Donc dans l'affichage il faut faire abstraction de cela, soit indiquer la dernière valeur reçus au temps t actuel, soit indiquer sur le graphisme la dernière valeur reçue au temps n (moment de réception)

Si un PC plante, alors le serveur ne peut lui envoyer des informations, et le client ne peut en recevoir, le serveur informe les autres clients que le client planté n'est plus disponible.

[billynirvana]

Comme tu l'as compris et bien expliqué avec ton exemple, c'est ma crainte.

C'est pour cela que j'ai pensé que le serveur doit faire "patienter" les clients le temps que chacun ait envoyé la donnée. au bout d'un timeout si c'est réalisable

C'est comme le principe de rendez vous:

les pointilles sont le temps d'envoi des données des clients vers le serveur.

Code :

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

1
2
3
4
n1---   |
n2------|
n3--    |
n4---   |

le serveur synchronise les clients et envoie un broadcast les infos.

Code :

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

1
2
3
4
n1---              |
n2----------------x|
n3--               |
n4---              |

Avec un timeout défini, le serveur détecte que n2 est mort (avec le x comme fin de timeout), et donc supprime de la liste ce client. Il envoie donc le résultat à n1, n3 et n4.



Tu veux donc dire que dans les jeux vidéos, chaque joueur est décalé dans le temps?

[Ti-R]

Oui tout le monde est "décalé", déjà personne n'a le même ping vis-à-vis du serveur et la plupart des protocoles réseau utilisé sont basé sur l’utilisation du TCP dans les jeux, vu qu'on ne peut faire de broadcast en TCP, forcément, les informations ne sont pas envoyé en même temps.

Je ne ferais pas comme cela pour ton serveur, faire attendre les clients me semble une mauvaise idée.
Pour moi les informations circule librement à la vitesse de chacun, mais c'est le client au final qui formate les données et affiche ce qu'il faut afficher à la fin avec les données reçues et collectées.

[billynirvana]

Donc tu supposes que je mette en place un reseau complet?

[Ti-R]

Donc tu supposes que je mette en place un reseau complet?

Je n’ai pas compris-la...

Si je prends une analogie assez grossière certes, mais qui correspond à ton cas, un chat avec un serveur et des clients.

Chaque client envoie des messages, le serveur traite les données (messages) et les renvoient aux clients.

Réfléchi sur le fonctionnement du tout, le principe est le même !

[billynirvana]

Ok, je vais le bosser sur papier et puis je reviendrai... vite


Merci pour tes lumières!

[billynirvana]

J'ai appliqué ta méthode, et cela marche bien. J'ai même volontairement fait lagué un pc pour voir (avec un Thread.sleep()), et ca lague correctement! Sur le moniteur de chaque client, la stat correspondant au pc lageur "est plus grossière".

Reste plus qu'à épurer mon code, et je posterai une partie.

Merci Ti-R pour tes conseils

Cordialement,


Kurt

[Ti-R]

Pas de problème, merci du retour , on est la pour cela en même temps

[orelero]

Excusez moi, c'est quoi pour vous du broadcasting en UDP ? Merci.

[Ti-R]

Tout est expliqué sur wikipédia.

Wikipédia - Broadcast
Wikipédia - Multicast

Si cela ne suffit pas, on essayera de clarifier

[orelero]

Ok merci Ti-Rex. En fait je me demandais si on pouvait étendre cette possibilité sur internet parcequ'il me semble que le multicasting n'est réservé que pour les opérateurs internet

[Ti-R]

Je ne crois pas que cela soit exclusif aux opérateurs.

Les web radio fonctionne sur ce principe, et je ne pense pas qu'ils aient signé de contrat spécifique.

Logiquement ce sont les "serveurs noeuds" du réseau qui dispatche l'information.

Donc au lieu d'envoyer un datagram à 1 personne, une liste de personnes est ajoutée et les serveurs se chargeront de les envoyer pour ces personnes.

Et ce n'est pas certain que ces même datagrams arrivent à destination, car ils ont une "vie", un nombre de noeuds qu'ils peuvent parcourir avant de mourir.

[orelero]

okay, ça serait génial si c'était vraiment possible ! En java :
http://www.javaspecialists.co.za/arc...r.do?issue=028
Ca me parait un peu facile ,...Autre chose : j'en ai jamais entendu parlé sur les forums, ça n'est donc que trés peu utilisé ? Pourquoi ?

Et ce n'est pas certain que ces même datagrams arrivent à destination, car ils ont une "vie", un nombre de noeuds qu'ils peuvent parcourir avant de mourir.

==>

Emission de datagrammes multicast
Par défaut les datagrammes multicast sont envoyés avec un TTL (time-to-live) de 1 qui correspond au sous-réseau sur lequel est physiquement connecté la machine par son interface ethernet. Le TTL contrôle la porté de l'émission. Habituellement un TTL de 15 permet de diffuser les datagrammes sur le site entier, un TTL de 47 permet une diffusion nationale et un TTL de 127 et au-delà une diffusion mondiale.

Mais si c'est du multicast en tcp, je suis sûr que ça arrive ?