Quel est l’intérêt d’utiliser UDP avec NIO?

NIO et TCP forment une excellente paire pour de nombreuses connexions. Puisqu’une nouvelle connexion doit être ouverte pour chaque nouveau client, chacun de ces clients aurait généralement besoin de son propre thread pour bloquer les opérations d’E / S. NIO résout ce problème en permettant aux données d’être lues quand elles le peuvent, plutôt que de les bloquer jusqu’à ce qu’elles soient disponibles. Mais qu’en est-il de l’UDP?

Je veux dire, UDP sans connexion ne possède pas la nature bloquante de TCP en raison de la conception du protocole (envoyez-le et oubliez-le, fondamentalement). Si je décide d’envoyer des données à une adresse, il le fera sans délai (sur la fin du serveur). De même, si je veux lire des données, je peux simplement recevoir des paquets individuels provenant de différentes sources. Je n’ai pas besoin d’avoir beaucoup de connexions dans de nombreux endroits en utilisant plusieurs threads pour traiter chacun d’eux.

Alors, comment NIO et les sélecteurs améliorent-ils UDP? Plus précisément, quand préféreriez-vous utiliser UDP avec NIO plutôt que le java.net paquet java.net ?

La méthode DatagramSocket.receive(...) est documentée comme une opération de blocage . Ainsi, par exemple, si vous avez un thread qui essaie de gérer les paquets de N sockets différents, vous devez utiliser NIO et des sélecteurs. De même, si le thread devait multiplexer la vérification de nouveaux paquets avec d’autres activités, vous pouvez le faire.

Si vous n’avez pas ces exigences ou des exigences similaires, les sélecteurs ne vous aideront pas. Mais ce n’est pas différent du cas TCP. Vous ne devriez pas utiliser de sélecteurs avec TCP si vous n’en avez pas besoin, car cela appendait potentiellement un appel système supplémentaire.

(Sous Linux, dans le cas du datagramme, vous feriez un appel syscall select suivi d’un recv … au lieu d’un simple recv .)


Mais si vous ne travaillez qu’avec un seul DatagramSocket, la méthode de réception ne lira-t-elle pas les paquets dès leur arrivée, indépendamment du fait qu’ils proviennent d’un autre ordinateur?

Si vous écoutez les datagrammes de “tout le monde” sur un même socket, alors oui. Si vous avez différents sockets pour différents ordinateurs, alors non.

Et pour le commentaire TCP, l’utilisation d’un sélecteur est parfois justifiée par le simple fait que des milliers de threads exigent beaucoup de ressources, comme le ferait un serveur TCP bloquant.

Nous ne discutions pas de ce cas. Mais oui, c’est vrai. Et la même chose est vraie si vous avez des milliers de threads bloquant sur UDP.

Ce que je voulais dire, c’est que vous n’avez pas beaucoup de threads, ou que le blocage d’ un thread importe peu, NIO ne vous aide pas. En fait, cela peut réduire les performances.

NIO supprime totalement le besoin de threads. Il vous permet de gérer tous vos clients dans un seul thread, y compris les clients TCP et UDP.

UDP sans connexion n’a pas la nature bloquante de TCP qui lui est associée

Ce n’est pas vrai. Reçoit toujours le blocage, et peut donc envoie, au moins en théorie.