java.net gegenüber java.nio

Question

An welchem Punkt ist es besser zu wechseln java.net zu java.nio?.net (nicht Microsoft entity) ist leichter zu verstehen und besser kennen, während nio skalierbar ist, und kommt mit einigen zusätzlichen nette features.

Speziell, die ich brauche, um eine Lösung für diese situation:Wir haben eine control center verwalten von hardware auf mehreren remote-Standorten (jeder Seite mit einem computer zur Verwaltung mehrerer hardware-Einheiten (transceiver, TNC und rotator)).Meine Idee war, schreiben Sie eine Server-app auf jedem Gerät fungiert als gateway von control center zu die radio der hardware, die mit einer Steckdose für jedes Gerät.Von meinem Verständnis, NIO gemeint ist, für ein server, viele clients, aber was ich denke, ist ein Kunde, vielen Servern.

Ich nehme an, eine Dritte option ist die Verwendung von MINA, aber ich bin mir nicht sicher, ob das werfen zu viel auf ein einfaches problem.

---

Jede remote-server haben bis zu 8 verbindungen, die alle aus dem gleichen client (zur Kontrolle, alle die hardware, und trennen Sie TX/RX-Anschlüsse).Der single-client eine Verbindung herstellen möchten, mehrere Server auf einmal, obwohl.Anstatt jeden server an verschiedenen ports, ist es möglich, channel-Selektoren auf der client-Seite, oder ist es besser zu gehen multi-threaded io auf der client-Seite der Dinge, und konfigurieren Sie den Server anders?

---

Tatsächlich, da Sie die remote-Maschinen, die nur dazu dienen, die Interaktion mit anderen hardware, würde RMI oder IDL/CORBA-die bessere Lösung?Wirklich, ich möchte nur in der Lage sein, um Befehle zu senden und empfangen Telemetrie von der hardware und müssen nicht auf make-up einige Anwendungs-layer-Protokoll, es zu tun.

Answer 1

Skalierbarkeit wird wahrscheinlich fahren Sie Ihr Wahl-Paket.java.net benötigen Sie einen thread pro socket.Kodierung es wird erheblich einfacher sein.java.nio ist viel mehr effizient, aber es kann haarig-code um.

Ich würde Fragen, wie viele verbindungen Sie erwarten Handhabung.Wenn es relativ wenige (sagen, < 100), würde ich gehen mit java.net.

Answer 2

Vermeiden NIO-es sei denn, Sie haben einen guten Grund, es zu benutzen. Es ist nicht so viel Spaß und sind möglicherweise nicht so vorteilhaft, wie Sie denken würden.Sie erhalten möglicherweise eine bessere Skalierbarkeit, sobald Sie den Umgang mit Zehntausenden von verbindungen, aber bei niedrigeren zahlen, die Sie erhalten wahrscheinlich einen besseren Durchsatz mit blockieren IO.Wie immer, obwohl, machen Sie Ihre eigenen Messungen, bevor Sie sich auf etwas, das Sie möglicherweise bereuen.

Etwas anderes zu prüfen, ist, dass, wenn Sie wollen, um SSL zu verwenden, NIO, macht es extrem schmerzhaft.

Answer 3

Es gibt fast keinen Grund, dies zu schreiben, Art der Netzwerk-code von Grund auf neu jetzt.Pakete wie netty.io fast immer bekommen Sie zuverlässiger und flexibler code mit weniger Zeilen code als eine hand-crafted Lösung.Auch mit Netty, können Sie die SSL-Unterstützung w/o erschweren Ihre Umsetzung auf allen.Bibliotheken wie netty auch vermeiden das "async-vs-threads" Frage fast vollständig, gibt Ihnen eine gute Leistung, und kann man noch optimieren, das threading-Modell, wie gebraucht.

Answer 4

Die Anzahl der verbindungen, die Sie zu reden, erzählt mir, die Sie verwenden sollten java.net.Wirklich, es gibt keinen Grund zu complexify Ihre Aufgabe mit non-blocking I/O.(Es sei denn, Ihre remote-Systeme sind untermotorisiert, aber warum sind Sie dann mit Java auf Sie?)

Werfen Sie einen Blick auf Apache XML-RPC Paket.Es ist einfach zu bedienen, komplett verdeckt das Netzwerk-Zeug aus Ihnen, und die Werke über das gute ol' HTTP.Keine Notwendigkeit zu sorgen über protokollarische Fragen ...Sie sehen alle wie die Methode aufruft, um Sie auf beide enden.

Answer 5

Angesichts der geringen Anzahl von verbindungen beteiligt, java.net klingt wie die richtige Lösung.

Andere Plakate Sprachen über die Verwendung von XML-RPC.Dies ist eine gute Wahl, wenn das Volumen der Daten, die geliefert werden, sind klein, aber ich habe schlechte Erfahrungen mit XML-basierter Protokolle beim schreiben von inter-Prozess-Kommunikation, Schiff große Mengen von Daten (z.B.große Anforderungen/Antworten, oder häufige kleine Mengen von Daten).Die Kosten für die XML-Analyse ist in der Regel um Größenordnungen höher als weitere optimiert Draht-Formate (z.B.ASN.1).

Für low-volume-control-Anwendungen, die die Einfachheit von XML-RPC sollte überwiegen die performance Kosten.Für high-volume-Daten-Kommunikation kann es besser sein, auf eine mehr effiziente wire protocol.