java.net contre java.nio

Question

À quel moment vaut-il mieux passer de java.net à java.nio? .net (pas l’entité Microsoft) est plus facile à comprendre et plus familier, tandis que nio est évolutif et comporte quelques fonctionnalités très utiles.

Plus précisément, je dois faire un choix pour cette situation: nous avons un centre de contrôle gérant le matériel sur plusieurs sites distants (chaque site avec un ordinateur gérant plusieurs unités matérielles (un émetteur-récepteur, une TNC et un rotateur)). Mon idée était d’écrire sur chaque machine une application de serveur qui servirait de passerelle entre le centre de contrôle et le matériel radio, avec une prise pour chaque unité. De ma compréhension, NIO est destiné à un serveur, plusieurs clients, mais ce que je pense à un seul client, plusieurs serveurs.

Je suppose qu'une troisième option consiste à utiliser MINA, mais je ne suis pas sûr que cela jette trop de problèmes simples.

Chaque serveur distant aura jusqu'à 8 connexions, toutes issues du même client (pour contrôler tout le matériel et des prises TX / RX distinctes). Le client unique voudra cependant se connecter à plusieurs serveurs à la fois. Au lieu de placer chaque serveur sur des ports différents, est-il possible d'utiliser des sélecteurs de canaux côté client ou vaut-il mieux passer en revue plusieurs opérations sur le côté client et configurer les serveurs différemment?

En fait, étant donné que les machines distantes servent uniquement à interagir avec un autre matériel, une solution RMI ou IDL / CORBA serait-elle une meilleure solution? En réalité, je veux juste pouvoir envoyer des commandes et recevoir une télémétrie du matériel, sans avoir à créer de protocole de couche d'application pour le faire.

Answer 1

L’évolutivité déterminera probablement votre choix de package. java.net nécessitera un thread par socket. Le codage sera beaucoup plus facile. java.nio est beaucoup plus efficace, mais il peut être difficile de coder.

Je vous demanderais combien de connexions vous comptez gérer. Si c'est relativement peu (disons, & Lt; 100), j'irais avec java.net.

Answer 2

Évitez NIO à moins d’avoir une bonne raison de l’utiliser. Ce n'est pas très amusant et peut ne pas être aussi bénéfique que vous penserait . Vous pouvez obtenir une meilleure évolutivité une fois que vous avez affaire à des dizaines de milliers de connexions, mais à des nombres inférieurs, vous obtiendrez probablement un meilleur débit avec le blocage d'IO. Comme toujours, faites vos propres mesures avant de vous engager dans quelque chose que vous pourriez regretter.

Un autre élément à prendre en compte est que si vous souhaitez utiliser SSL, NIO le rend extrêmement pénible.

Answer 3

Il n’ya pratiquement aucune raison d’écrire ce type de code réseau à partir de maintenant. Des packages tels que netty.io vous procureront presque toujours un code plus fiable et plus souple comportant moins de lignes de code qu'une solution personnalisée. volonté. De plus, avec Netty, vous pouvez obtenir un support SSL sans compliquer votre mise en œuvre. Des bibliothèques comme netty suppriment également le & Quot; async vs threads & Quot; la question presque entièrement, vous donne de bonnes performances, et vous permet toujours de peaufiner le modèle de thread si nécessaire

Answer 4

Le nombre de connexions dont vous parlez me dit que vous devriez utiliser java.net. En réalité, il n'y a aucune raison de complexifier votre tâche avec des E / S non bloquantes. (À moins que vos systèmes distants soient sous-alimentés, mais pourquoi utilisez-vous Java sur ces systèmes?)

Consultez le paquet XML-RPC d'Apache. Il est facile à utiliser, cache complètement le réseau, et fonctionne avec le bon vieux HTTP. Inutile de vous inquiéter des problèmes de protocole ... cela ressemblera à des appels de méthode, des deux côtés.

Answer 5

Compte tenu du petit nombre de connexions impliquées, java.net semble être la bonne solution.

D'autres affiches ont parlé de l'utilisation de XML-RPC. C’est un bon choix si les volumes de données expédiés sont petits. Toutefois, j’ai eu de mauvaises expériences avec les protocoles XML lors de l’écriture de communications interprocessus contenant de grandes quantités de données Les données). Le coût de l'analyse XML est généralement supérieur d'un ordre de grandeur à celui de formats de fil optimisés (ASN.1, par exemple).

Pour les applications de contrôle de faible volume, la simplicité de XML-RPC devrait l'emporter sur les coûts de performance. Pour les communications de données à volume élevé, il peut être préférable d’utiliser un protocole filaire plus efficace.