NIO und TCP bilden ein gutes Paar für viele Verbindungen. Da für jeden neuen Client eine neue Verbindung geöffnet werden muss, benötigt jeder dieser Clients normalerweise einen eigenen Thread zum Blockieren von E / A-Vorgängen. NIO löst dieses Problem, indem es das Lesen von Daten erlaubt, wenn es möglich ist, und nicht blockiert, bis es verfügbar ist. Aber was ist mit UDP?
Ich meine, verbindungsloses UDP hat nicht die blockierende Natur von TCP, die damit verbunden ist, wie das Protokoll entworfen ist (sende es und vergesse es im Grunde). Wenn ich entscheide, einige Daten an eine Adresse zu senden, geschieht dies ohne Verzögerungen (am Server-Ende). Wenn ich Daten lesen möchte, kann ich auch einzelne Pakete aus verschiedenen Quellen empfangen. Ich brauche nicht viele Verbindungen zu vielen Orten mit vielen Threads, um mit jedem von ihnen umzugehen.
Wie verbessern NIO und Selektoren UDP? Genauer gesagt, wann würde man lieber UDP mit NIO verwenden als das alte% java.net -Paket?
Nun, die Methode DatagramSocket.receive(...) ist als eine blockierende Operation dokumentiert. Wenn Sie beispielsweise einen Thread haben, der versucht, Pakete von N verschiedenen Sockets zu verarbeiten, müssen Sie NIO und Selektoren verwenden. In ähnlicher Weise könnten Sie das tun, wenn der Thread die Prüfung auf neue Pakete mit anderen Aktivitäten multiplexen müsste.
Wenn Sie diese oder ähnliche Anforderungen nicht haben, werden Selektoren nicht helfen. Aber das ist nicht anders als beim TCP-Fall. Sie sollten Selektoren nicht mit TCP verwenden, wenn Sie sie nicht benötigen, da möglicherweise einen zusätzlichen Systemaufruf hinzufügt.
(Unter Linux würden Sie im Datagrammfall einen select syscall gefolgt von einem recv ... statt nur einem recv ausführen.)
Aber wenn Sie nur mit einem DatagramSocket arbeiten, würde die Empfangsmethode die Pakete nicht sofort beim Eintreffen lesen, ungeachtet der Tatsache, dass sie von einem anderen Computer stammen?
Wenn Sie an einer Buchse für Datagramme von "Jeder" hören, dann ja. Wenn Sie verschiedene Sockets für verschiedene Computer haben, dann nein.
Und für den TCP-Kommentar wird manchmal die Verwendung eines Selektors einfach durch die Tatsache gerechtfertigt, dass es sehr ressourcenintensiv ist, Tausende von Threads zu haben, wie es von einem blockierenden TCP-Server benötigt würde.
Wir haben diesen Fall nicht besprochen. Aber ja, das stimmt. Und das gleiche gilt, wenn Sie Tausende von Threads blockiert auf UDP empfängt.
Mein Punkt war, dass Sie nicht viele Threads haben oder wenn keine Rolle spielt , wenn ein Thread blockiert, dann hilft NIO nicht. In der Tat kann es die Leistung reduzieren.
NIO beseitigt die Notwendigkeit für Threads insgesamt. Damit können Sie alle Ihre Clients in einem Thread behandeln, einschließlich TCP- und UDP-Clients.
verbindungsloses UDP ist nicht mit der blockierenden Natur von TCP verbunden
Das ist nicht wahr. Empfängt immer noch Block und kann so zumindest theoretisch senden.
Tags und Links java networking tcp nio udp