Discussion :

[MrEddy]

Bonjour,

Je suis a la recherche de la meilleure méthode afin de faire communiquer un programme java (serveur) et plusieurs clients java.
Je me suis intéressé à RMI, JMS, CORBA, les sockets et je pense que cette dernière serait la plus adaptée pour mon besoin.
Je pense créer 3 jar, le serveur, le client et un jar contenant les classes (de données) utilisées par le serveur et le client qui seront sérialisées/désérialisés et transmis par socket du serveur au client.

Cependant j'ai quelques questions :
Mes programmes clients sont bien des clients dans le sens ou ils font des requêtes au serveur, et traite le résultat du serveur. Cependant il arrive aussi que le serveur doit envoyer des informations a tous les clients en fonctionnement, c'est a dire lorsqu'un des clients fait une demande au serveur, le serveur doit avertir de cette action tous les autres clients en fonctionnement. Pour cela est ce que chaque client doivent être également un serveur ? Si c'est le cas, est ce que je peux utiliser le même port pour écouter que pour envoyer des informations au serveur ou bien chaque client/serveur devra avoir un port qu'il faudra envoyer au serveur pour qu'il puisse en suite communiquer avec eux ?

Merci de votre attention

[CastorJoyeux]

tu n'aura qu'un seul serveur. Les sockets sont bidirectionnelles, donc ton serveur pourra très bien envoyer des données au client par celle-ci, c'est d'ailleurs déjà ce qu'il fait quand il envoie la réponse au client

[MrEddy]

Même quand le client ne fait pas de requete vers le serveur, le serveur peut qd il le souhaite envoyer une réponse au client ?

[CastorJoyeux]

une fois la socket ouverte par le client vers le serveur et tant qu'elle reste ouverte, ca ne pose aucune problème autre que le fait que ton client dois bien entendu s'attendre, dans ce genre de cas, à recevoir via le socket.getInputStream() des messages qui ne sont pas nécessairement des réponses à ce qu'il a demandé. Exemple de ce que pourrais voir le client

Envoi de l'event XY
Réception de l'event ABC
Réception de l'event DEF
Réception de la réponse à XY
Réception de l'event GHI

[_Xavier_]

Cependant il arrive aussi que le serveur doit envoyer des informations a tous les clients en fonctionnement, c'est a dire lorsqu'un des clients fait une demande au serveur, le serveur doit avertir de cette action tous les autres clients en fonctionnement. Pour cela est ce que chaque client doivent être également un serveur ?

Les clients seront dans ce cas des serveurs dans la mesure où ils sont constamment à l'écoute d'événements.

[MrEddy]

Ah ok, donc le client ne doit pas fermer sa classe Socket pendant toute la durée d'exécution du programme.

[CastorJoyeux]

non, en même temps si tu veux garder une communication permanente entre client et serveur, vaut mieux, réouvrir une socket à chaque fois c'est une belle perte de perfs

Sauf bien sur si t'as quelque chose genre un message par heure qui transite sur le réseau là il vaut mieux effectivement envisager autre chose

[MrEddy]

Dans mon cas il n'y aura pas beaucoup de message envoyé donc c'est dommage de garder une connexion ouverte en permanence, a quelle autre solution penses tu ?

[CastorJoyeux]

Dans ce cas, ca dépendra du type d'application, du contexte dans lequel elle sera utilisé, de la charge estimée en terme de quantité de données et de clients, etc....

[MrEddy]

D'ac merci pour toutes les infos, je vais voir si en faisant un programme client qui écoute également via un socketserver peut faire l'affaire

[_Xavier_]

D'ac merci pour toutes les infos, je vais voir si en faisant un programme client qui écoute également via un socketserver peut faire l'affaire

En principe c'est ça que tu dois faire, car un client même s'il n'envoie jamais de message est susceptible d'en recevoir.

[CastorJoyeux]

a noter que si tes client sont en adresse privée (genre derrière un routeur adsl), les socketserver, c'est tintin

[MrEddy]

Non ça sera dans un réseau local, merci pour ces précisions