Ils offrent tous deux à peu près la même fonctionnalité. Lequel dois-je choisir pour développer mon serveur TCP haute performance ? Quels sont les avantages et les inconvénients ?
Liens de référence :
Apache MINA ( source )
Ils offrent tous deux à peu près la même fonctionnalité. Lequel dois-je choisir pour développer mon serveur TCP haute performance ? Quels sont les avantages et les inconvénients ?
Liens de référence :
Apache MINA ( source )
Bien que MINA et Netty aient des ambitions similaires, ils sont très différents dans la pratique et vous devez considérer votre choix avec soin. Nous avons eu la chance d'avoir beaucoup d'expérience avec MINA et d'avoir le temps de jouer avec Netty. Nous avons particulièrement apprécié l'API plus propre et la bien meilleure documentation. Les performances semblaient également meilleures sur le papier. Mais surtout, nous savions que Trustin Lee serait là pour répondre à toutes nos questions, ce qu'il a fait.
Nous avons trouvé tout plus facile dans Netty. Période. Alors que nous essayions de réimplémenter la même fonctionnalité que nous avions déjà sur MINA, nous l'avons fait en partant de zéro. En suivant l'excellente documentation et les exemples, nous avons obtenu plus de fonctionnalités avec beaucoup, beaucoup moins de code.
Le Pipeline Netty a mieux fonctionné pour nous. Il est en quelque sorte plus simple que MINAs, où tout est un gestionnaire et c'est à vous de décider si vous voulez gérer les événements en amont, les événements en aval, les deux ou consommer des choses plus bas niveau. Le fait de gober des octets dans des décodeurs "rejoueurs" était presque un plaisir. C'était également très agréable de pouvoir reconfigurer le pipeline à la volée aussi facilement.
Mais l'attraction principale de Netty, à mon avis, est la possibilité de créer des gestionnaires de pipeline avec une "couverture de un". Vous avez probablement déjà lu cette annotation de couverture dans la documentation, mais essentiellement, elle vous donne l'état dans une seule ligne de code. Sans s'embrouiller, sans cartes de session, sans synchronisation et autres choses de ce genre, nous avons simplement pu déclarer des variables normales (disons "username") et les utiliser.
Mais ensuite, nous avons rencontré un obstacle. Nous avions déjà un serveur multi-protocole sous MINA, dans lequel notre protocole d'application fonctionnait sur TCP/IP, HTTP et UDP. Lorsque nous sommes passés à Netty, nous avons ajouté SSL et HTTPS à la liste en quelques minutes ! Jusqu'ici tout allait bien, mais lorsqu'il s'est agi de l'UDP, nous avons réalisé que nous avions fait une erreur. MINA était très gentil avec nous, car nous pouvions traiter UDP comme un protocole " connecté ". Avec Netty, cette abstraction n'existe pas. UDP est sans connexion et Netty le traite comme tel. Netty expose davantage la nature sans connexion de UDP à un niveau inférieur que MINA. Il y a des choses que vous pouvez faire avec UDP sous Netty que vous ne pouvez pas faire avec l'abstraction de plus haut niveau que fournit MINA, mais sur laquelle nous nous sommes appuyés.
Il n'est pas si simple d'ajouter un wrapper "connected UDP" ou autre. Compte tenu des contraintes de temps et sur le conseil de Trustin qui nous a dit que la meilleure façon de procéder était d'implémenter notre propre fournisseur de transport dans Netty, ce qui ne serait pas rapide, nous avons finalement dû abandonner Netty.
Examinez donc attentivement les différences entre elles et parvenez rapidement à un stade où vous pouvez tester que toute fonctionnalité délicate fonctionne comme prévu. Si vous êtes convaincu que Netty fera l'affaire, je n'hésiterais pas à le préférer à MINA. Si vous passez de MINA à Netty, la même chose s'applique, mais il convient de noter que les deux API sont vraiment très différentes et que vous devriez envisager une réécriture virtuelle pour Netty - vous ne le regretterez pas !
Re : commentaire précédent de Josh sur le manque de support pour UDP dans Netty : Je ne comprends pas pourquoi vous ne pourriez pas utiliser quelques pages de code artisanal pour faire ce dont vous avez besoin, plutôt que d'abandonner Netty. UDP écoute sur un port différent de toute façon. J'ai testé Netty par rapport à Nginx et je suis assez impressionné (Netty obtient des résultats à peu près identiques, voire meilleurs, sous charge).
Mise à jour : utilisez simplement Netty . Il s'agit désormais d'un projet mature, doté de toutes les fonctionnalités nécessaires à la construction de clients et de serveurs de protocole. Il possède une forte communauté avec plusieurs contributeurs actifs soutenus par des entreprises. Il existe également un livre, ' Netty en action '. Il a été adopté par de nombreuses entreprises et projets de renom déjà. Contrairement à Netty, Apache MINA est en mode maintenance depuis que j'ai quitté le projet.
MINA offre davantage de fonctionnalités prêtes à l'emploi, mais au prix d'une certaine complexité et de performances relativement faibles. Certaines de ces fonctionnalités ont été intégrées dans le noyau de manière trop étroite pour être supprimées même si elles ne sont pas nécessaires à l'utilisateur. Dans Netty, j'ai essayé de résoudre ces problèmes de conception tout en conservant les forces connues de MINA.
Actuellement, la plupart des fonctionnalités disponibles dans MINA le sont également dans Netty. À mon avis, Netty a une API plus propre et mieux documentée puisque Netty est le résultat d'une tentative de reconstruire MINA à partir de zéro et de résoudre les problèmes connus. Si vous trouvez qu'une fonctionnalité essentielle est manquante, n'hésitez pas à poster votre suggestion sur le forum. Je serai heureux de répondre à votre demande.
Il est également important de noter que Netty a un cycle de développement plus rapide. Il suffit de vérifier la date de sortie des dernières versions. De plus, vous devez tenir compte du fait que l'équipe MINA va procéder à une réécriture majeure, MINA 3, ce qui signifie qu'elle va rompre complètement la compatibilité avec l'API.
@trustin, j'ai trouvé que Netty 5.0 ne fournit pas beaucoup de documents avancés, et le matériel web actuel avec d'autres versions ne fonctionnerait pas. Avez-vous un lien recommandé pour un tutoriel mina intermédiaire et avancé ? merci
@trustin y a-t-il une mise à jour que vous pouvez faire à cette réponse ? Le MINA semble avoir été en grande partie abandonné, et aucun MINA 3 n'a jamais été achevé ?
J'ai testé les performances de 2 implémentations de "Google Protobuffer RPC" dont l'une était basée sur Netty (netty-protobuf-rpc) et l'autre sur mina (protobuf-mina-rpc). Netty s'est avéré être systématiquement plus rapide ( +- 10% ) pour toutes les tailles de messages - ce qui confirme la performance globale annoncée sur le site web de Netty. Comme vous voulez tirer le maximum d'efficacité de votre code lorsque vous utilisez une telle bibliothèque RPC, j'ai fini par écrire protobuf-rpc-pro basé sur Netty. J'ai utilisé MINA dans le passé, mais je trouve que leur documentation sur la version 2.0 a de gros trous, et que la rupture de la compatibilité ascendante de l'API est un gros inconvénient.
MINA et Netty ont été initialement conçus et réalisés par le même auteur. C'est pourquoi ils sont si semblables l'un à l'autre. MINA est conçu à un niveau légèrement supérieur avec un peu plus de fonctionnalités, tandis que Netty est un peu plus rapide. Je pense qu'il n'y a pas beaucoup de différence, les concepts de base sont les mêmes.
Sur le site Netty, vous pouvez trouver quelques performances rapports . Comme prévu :-) ils désignent Netty comme le framework le plus performant.
Je n'ai jamais utilisé Netty, mais j'ai déjà utilisé MINA pour implémenter un protocole TCP. L'implémentation de l'encodage et du décodage était facile, mais celle de la machine à états ne l'était pas autant. MINA fournit quelques classes pour vous aider à implémenter la machine à états, mais je les ai trouvées un peu difficiles à utiliser. Finalement, nous avons décidé d'abandonner MINA et d'implémenter le protocole à partir de zéro, et étonnamment, nous avons obtenu un serveur plus rapide.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
6 votes
Il serait également intéressant d'ajouter Grizzly à la comparaison.
0 votes
Le Grizzly est une bête complètement différente. Il y a même eu l'idée d'un support de Grizzly pour MINA, lorsque les deux groupes ont discuté.
1 votes
@Hardcoded vous dites que le grizzly est une bête complètement différente, je suis un nouveau venu dans ce domaine, pouvez-vous s'il vous plaît indiquer les différences ou me donner un article à lire sur ce sujet ? Je vous en serais reconnaissant.
1 votes
Grizzly a un passé différent et la dernière fois que je l'ai regardé, il était surtout adapté aux applications basées sur HTTP. Je viens de regarder les exemples et j'ai été surpris de voir qu'ils utilisent une structure très similaire à celle de MINA ou Netty. La bête n'est donc plus si différente.