L'efficacité de while(true) ServerSocket Écouter

Je me demande si une typique while(true) ServerSocket écouter en boucle prend un ensemble de base d'attendre et d'accepter un client de connexion (Même lors de la mise en œuvre de exécutables, et à l'aide de Thread .start())

Je me suis mise en œuvre d'un type de l'informatique distribuée cluster et chaque ordinateur a besoin de tous les cœurs qu'il a pour le calcul. Un nœud Maître a besoin de communiquer avec ces ordinateurs (en invoquant des méthodes statiques qui modifie l'algorithme de fonctionnement).

La raison pour laquelle je besoin pour utiliser des sockets est due à la croix de plate-forme /croix capacités linguistiques. Dans certains cas, PHP va être l'appel de ces java des méthodes statiques.

J'ai utilisé un java profiler (YourKit) et je peux voir ma course ServerSocket écouter fil et il ne dort jamais et il est toujours en cours d'exécution. Est-il une meilleure approche de faire ce que je veux? Ou bien, l'impact sur les performances être négligeable?

N'hésitez pas à proposer des suggestions, si vous pouvez penser à une meilleure façon (j'ai essayé de RMI, mais il n'est pas pris en charge inter-langue.

Merci à tous

Donc ne devrait pas se produire si vous utilisez "accepter". Pouvez-vous mettre un peu de code?
erickson était sur place avec le code, il a affiché while (true) { Socket socket = server.accept(); /* Faire quelque chose avec socket... */ }
Combien de connexions/seconde gérez-vous?
Droit maintenant, pas beaucoup. Cependant, cela pourrait facilement se transformer en une douzaine. L'information transmise est très petite, donc il ne devrait pas être beaucoup actives simultanées sockets

OriginalL'auteur Submerged | 2010-05-17

  1. 8

    Si vous voulez dire quelque chose comme ceci:

    while (true) {
  Socket socket = server.accept();
  /* Do something with socket... */
}

    alors, non, l'appel à accept() ne pas "prendre un ensemble du coeur." C'est un appel de blocage qui permet au CPU d'être programmé pour un autre thread jusqu'à ce qu'un client se connecte. Une fois l'appel à accept() retourne, le thread en cours seront planifiées pour s'exécuter et consomment du CPU jusqu'à ce qu'il bloque sur accept() dans la prochaine itération de la boucle.

    Pour éviter de l'écouter carnet de commandes d'autres clients devient trop importante, un autre thread s'occupe habituellement de l'interaction avec les nouvelles accepté Socket, laissant un thread pour se concentrer sur l'acceptation de nouveaux clients. Le socket gestion des threads peuvent traiter de nombreux sockets, à l'aide de NIO, ou il peut être dédié à une seule prise, ce qui est beaucoup plus simple de code mais qui ne sont pas à l'échelle bien au-delà de plusieurs centaines de connexions simultanées.

    OriginalL'auteur erickson

  2. 5

    Vous voudrez peut-être jeter un oeil à la Java 1.4 nio bibliothèques et en particulier ServerSocketChannel. J'utilise ce avec beaucoup de succès à mettre en œuvre efficace d'un serveur, la clé des morceaux de code sont:

    Selector selector = Selector.open();

ServerSocketChannel server= ServerSocketChannel.open();
server.socket().bind(new java.net.InetSocketAddress(port));
server.configureBlocking(false);
SelectionKey serverKey = server.register(selector, SelectionKey.OP_ACCEPT);

//start listening thread
new Thread(listener).start();

    Et l'auditeur est juste une boucle qui s'exécute:

    selector.select(1000); //listen for one second max
Set<SelectionKey> keys = selector.selectedKeys();

if (keys.size()>0) {
    handleKeys(keys);
}
    J'étais à la recherche sur la prise de Canaux, merci pour l'affichage de cette!

    OriginalL'auteur mikera

  3. 3

    J'ai utilisé un java profiler (YourKit) et je peux voir ma course ServerSocket écouter fil et il ne dort jamais et il est toujours en cours d'exécution.

    Fondamentalement, le profileur est vous induire en erreur.

    Je suppose que votre code ressemble à ceci:

    ServerSocket server = ...
//configure server socket

try {
    while (true) {
        Socket socket = server.accept();
        //do something with socket (and close it afterwards!)
    }
} catch (InterruptedException ex) {
    //we're outta here!
}

    Ce ne sera pas consommer d'importantes ressources CPU ... sauf si vous avez fait quelque chose de pathologique, comme appeler ServerSocket.setSoTimeout(int) avec un petit délai d'attente.

    OriginalL'auteur Stephen C

  4. 0

    Laisser le noyau de dormir un peu. Dans votre Exécutable méthode, ajouter quelque chose comme

    Thread.sleep(250); //milliseconds

    dans chaque boucle.

    Qui devrait considérablement réduire l'utilisation du PROCESSEUR

    Edit: mauvaise idée, à voir les commentaires, désolé, ma faute

    Et de: ne pas utiliser while(true). c'est affreux de la conception, comme la sémantique suggère enfin que le vrai ne sera pas vrai. Habituellement, vous voulez à la requête de certains volatiles ou atomique de la variable dans le thread principal

    public class MyClass {

class MyRunnable implements Runnable {

    public void run() {
        while (MyClass.this.keepGoing.get()) {
            //listen();
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                //deal with exception
            }

        }
    }

}

private final AtomicBoolean keepGoing = new AtomicBoolean(true);

}

    De cette façon, le thread principal a un moyen d'arrêter le thread d'écoute.

    Je ne suis pas sûr que c'est une excellente idée, car il sera de la limite du taux de vos connexions.
    yup, j'ai mal lu la question. Je pensais que c'était juste un fil qui ont attendu pour certains services à démarrer, mais une Prise de courant auditeur qui écoute vraiment aux demandes des utilisateurs, c'est de mauvais conseils.
    salut , dans quel contexte vous avez voulu dire "vrai ne sera pas vrai" ?
    Je veux dire: ce que vous dites est "si cela est vrai est vrai, conserver". Toutefois, si vous avez une pause ou de jeter ou de l'instruction return n'importe où à l'intérieur de la boucle, vous êtes ce qui suggère que le vrai n'est plus vrai et qui est sémantiquement maladroit même si, techniquement, ok.
    OMI meilleure approche est de mettre la while (true) à l'intérieur le bloc try avec les captures pour InterruptedException.

    OriginalL'auteur Sean Patrick Floyd