Bonjour tlm,
 
Voici l'existant : j'ai créé une application client / serveur pour faire un chat. Et ça fonctionne bien. Le problème n'est pas là.
 
Pour le moment, mon serveur est affiché dans une JFrame : log affichée dans un textarea, boutons pour démarrer / arrêter le serveur.
 
Ca c'est bien pour les tests. Ensuite je vais placer le serveur sur une machine sur Ubuntu server --> Donc il n'y aura pas de JFrame possible. Je cherche donc à faire une petite variante du serveur actuel
 
 1 -> la log ne sera plus affichée dans un textarea mais stockée dans un fichier.   OK pour ça, c'est facile.
 2 ->   pour remplacer les boutons et pouvoir lancer / arrêter le serveur, j'aurai un truc du genre "java myServer start" et "java myServer stop". Mais comment coder ça ? Comment le lancement d'un "myServer stop" peut influer sur l'application lancée par le "myServer start". Quel est le moyen le plus propre ? sachant que je ne veut pas un kill brutal, il faut que le serveur finisse ses écritures sur fichier avant (et peut-être prévenir les clients....).    
 
ça doit pas être compliqué ... mais là je bloque. Faut dire que ça fait longtemps que je ne touchais plus au java    
 
Merci tout le monde

 
Euh je viens de penser à un truc tout bête ... une variable statique "mustStop" dans myServer.java ça suffirait pas?
 
myServer start
test régulier sur mustStop pour savoir si le process continu ou stop.
 
myServer stop
mustStop = true.
 
myServer status
System.out.println(mustStop)
 
non?

 
Je me répond tout seul : non ça ne marche pas...
 
J'ai donc utilisé un fichier.
 
A l'intérieur du fichier il y a un "ON" ou "OFF" et quand le serveur voit "OFF" dans le fichier il ferme proprement et s'arrête.
 
Si quelqu'un connait plus propre ... je suis preneur.

ce que fait tomcat par exemple, c'est a dire que ton serveur ouvre 2 sockets : celle de communication avec les clients, et celle de controle, sur laquelle tu peux lui envoyer des instructions de ce genre.
 
autre possibilité, tout sur la même socket, mais avec un protocole qui permet au serveur de savoir si c'est un message ou une commande.
 
avantage: tu peux le killer a distance.

 
Oui j'y ai pensé aussi à cette socket. Je me demandais si ça serait pas plus lourd...
Mais en fait c'est clair que la lecture régulière du fichier c'est pas très propre et pas super léger non plus.
 
Je crois que je vais opter pour pour l'option d'une seconde socket. C'est plus simple à gérer. L'existante est "formaté" pour recevoir bien dans l'ordre les infos du client avec déjà pas mal de contrôles.

J'ai une autre question pour ce chat :
 
Pour le moment, je n'ai que l'aspect "salon" : tout le monde voit ce que tout le monde écrit
Envoi Client --> Reception Serveur --> Envoi serveur à tout le monde (ou seulement à un destinataire si on coche une petite case du genre "message caché" ) --> Reception destinataire(s)
 
Maintenant je veux me mettre à l'aspect message privé. Et j'aimerais que cette partie ne surcharge pas trop le serveur, et donc que les deux applications clientes puissent communiquer directement entre elles.
 
PAS ClientA <--> Serveur <--> ClientB
Mais plutot ClientA <--> ClientB directement (une fois que le serveur leur à permis de le faire)
 
Ca peut être fait facilement si le serveur donne à un des 2 clients l'adresse IP et le port d'écoute de l'autre --> utilisation d'une socket.
Mais il y a t'il un moyen pour que chaque client ne puisse pas identifier l'autre. (+ sécurité / confidentialité)
Du genre : le serveur créé les sockets qui vont bien et les envois aux deux clients. Les clients peuvent donc utiliser les sockets mais ne pas faire de "getPort" ou "getInetAdress" ...
 
Il y a bien des socket sécurisées je crois mais c'est pour sécuriser les données échangées je crois et pas la confidentialité des destinataires et émetteurs.
 
Merci pour votre aide !

impossible, comment veux tu envoyer des données si tu ne sais pas ou ?  
soit ca circule par le serveur, soit les clients ont besoin de ce connaitre.
 
d'apres mon experience, tu ferais mieux de passer par le serveur, sinon on a des problemes avec les gens en nat, derriere des routeurs, ...
 
tu tu fais ca pour répondre a un vrai besoin (donc pas pour l'ecole), je ne peux que t'inviter a jeter un oeil a lucane, ou je fais justement ce genre de choses (+ crypto si nécéssaire)

C'est ni pour un réel besoin ... ni pour un projet (je suis développeur SAP ... et j'espère bientôt développeur Java/J2EE pour SAP)
 
En fait j'ai un petit challenge perso :
1- réalisation d'un site perso
     --> Presque fini
2- réalisation d'un chat (serveur + client applc java + client applet) qui sera justement dispo sur mon site
     --> Reste plus que l'aspect MP, d'où ce sujet
3- hébergement de tout cela
     --> Ordi sur Ubuntu (presque) prêt à héberger tout cela
 
Et donc tu cryptes tes données ... va falloir que j'y pense aussi ...
 
Merci pour ton aide, je vais donc utiliser les mêmes sockets que pour le mode salon.
 
Pour info, j'ai trois flux de socket.
1- Flux utilisé pour le transfert d'infos du client au serveur principalement : message, changement de couleurs d'écriture ...
    -> Serveur toujours à l'écoute
2- Flux utilisé pour le transfert d'infos du serveur au client principalement : messages d'autres clients
    -> Clients toujours à l'écoute
3- Flux d'administration (vu ensembles) pour contrôler le serveur.
    -> Serveur toujours à l'écoute
 
C'est comme ça que tu as fait également ?
 
Merci

C'est pourtant bien simple.
 
Ton serveur multithred doit posséder comme vous le disiez tout à l'heure un petit protocole afin de différencier le chat des commande de l'administrateur donc toi.
 
De plus lorsqu'une personne se connecte avec un nom à ton serveur multithread, celui-ci stocke le server fils dans une liste du serveur maitre genre :
 
/* Constructeur de la classe ServeurTCP */
  public ServeurMain(int p, ThreadPasserelle pass) {
    port = p;
    this.passerelle = pass;
    try {
      service = new ServerSocket(p);
    }
    catch (NotSerializableException e) {
      System.out.println("> SERVER : la classe a envoyer n'est pas sérialisable!" );
      this.setLog("Serversocket failed port "+this.port, "error : " );
    }
    catch(IOException e) {
      this.setLog("Serversocket failed port "+this.port, "error : " );
    }
    this.t = new Thread(this);
    //this.threadLTM = new Thread(manager);
    //this.threadLTM.start();
    System.out.println("Création Manager" );
    //time.start();
  }
 
  public void start() {
    t.start();
  }
 
  public void stop() {
    t.stop();
  }
 
 
  /* Méthode de lancement du Thread serveur TCP */
  public void run() {
    time.start();
    while(true) {
      try {
        connexion = service.accept(); //System.out.println("> SERVER service : "+connexion+" - "+service.isBound());
        if (connexion != null) {
          this.thread_s = new Server(connexion, 0, false);
          this.thread_s.start();
          this.thread_s.addObserver(this);
          this.listThreads.add(this.thread_s);
          System.out.println("> SERVER : Nouveau client" );
          this.passerelle.frame.jLabel3.setText("> SERVER : Nouveau client" );
        }
      }
      catch(IOException e) {
      System.out.println("> SERVER : l'acceptation de la socket cliente a échouée!" );
      this.setLog("Accepted Client socket failed", "error : " );
      this.setChanged();
      this.notifyObservers(this);
      }
    }
  }
.......
 
Après, lors de l'envoi d'un message, tu met un filtre de redirection tout simple (si privé alors destinataire contenu dans le coprs du message)