java.net contro java.nio

Question

A che punto è meglio passare da java.net a java.nio? .net (non l'entità Microsoft) è più facile da capire e più familiare, mentre nio è scalabile e include alcune funzionalità extra.

In particolare, devo fare una scelta per questa situazione: abbiamo un centro di controllo che gestisce l'hardware in diversi siti remoti (ogni sito con un computer che gestisce più unità hardware (un ricetrasmettitore, un TNC e un rotatore)). La mia idea era di scrivere un'app sever su ogni macchina che fungesse da gateway dal centro di controllo all'hardware radio, con una presa per ogni unità. Da quanto ho capito, NIO è pensato per un server, molti client, ma quello che sto pensando è un client, molti server.

Suppongo che una terza opzione sia quella di utilizzare MINA, ma non sono sicuro che ciò dia troppa importanza a un semplice problema.

---

Ogni server remoto avrà fino a 8 connessioni, tutte dallo stesso client (per controllare tutto l'hardware e socket TX / RX separati). Tuttavia, il singolo client vorrà connettersi a più server contemporaneamente. Invece di collocare ciascun server su porte diverse, è possibile utilizzare selettori di canale sul lato client o è meglio passare io multi-thread sul lato client delle cose e configurare i server in modo diverso?

---

In realtà, poiché le macchine remote servono solo per interagire con altri hardware, RMI o IDL / CORBA sarebbero una soluzione migliore? In realtà, voglio solo essere in grado di inviare comandi e ricevere telemetria dall'hardware e non dover inventare un protocollo a livello di applicazione per farlo.

Answer 1

La scalabilità probabilmente guiderà la scelta del pacchetto. java.net richiederà un thread per socket. La codifica sarà notevolmente più semplice. java.nio è molto più efficiente, ma può essere peloso da programmare.

Vorrei chiederti quante connessioni ti aspetti di gestire. Se è relativamente pochi (diciamo, & Lt; 100), sceglierei java.net.

Answer 2

Evita NIO a meno che tu non abbia una buona ragione per usarlo. Non è molto divertente e potrebbe non essere così vantaggioso come te penserei . Potresti ottenere una migliore scalabilità quando hai a che fare con decine di migliaia di connessioni, ma a numeri più bassi probabilmente otterrai un throughput migliore con il blocco dell'IO. Come sempre, fai le tue misurazioni prima di impegnarti in qualcosa di cui potresti pentirti.

Un'altra cosa da considerare è che se si desidera utilizzare SSL, NIO lo rende estremamente doloroso.

Answer 3

Non c'è quasi motivo di scrivere questo tipo di codice di rete da zero ora. Pacchetti come netty.io ti offriranno quasi sempre un codice più affidabile e flessibile con meno righe di codice rispetto a una soluzione artigianale volontà. Inoltre, con Netty, puoi ottenere il supporto SSL senza complicare affatto l'implementazione. Le librerie come netty ovviano anche al & Quot; async vs thread & Quot; domanda quasi interamente, ti dà buone prestazioni e ti consente ancora di modificare il modello di threading secondo necessità.

Answer 4

Il numero di connessioni di cui stai parlando mi dice che dovresti usare java.net. Davvero, non c'è motivo di complicare l'attività con l'I / O non bloccante. (A meno che i tuoi sistemi remoti non siano potenziati, ma allora perché stai usando Java su di essi?)

Dai un'occhiata al pacchetto XML-RPC di Apache . È facile da usare, ti nasconde completamente le cose di rete e funziona su un buon vecchio HTTP. Non c'è bisogno di preoccuparsi dei problemi del protocollo ... sembrerà tutto come una chiamata al metodo, ad entrambe le estremità.

Answer 5

Dato il piccolo numero di connessioni coinvolte, java.net sembra la soluzione giusta.

Altri poster hanno parlato dell'utilizzo di XML-RPC. Questa è una buona scelta se i volumi di dati inviati sono piccoli, tuttavia ho avuto brutte esperienze con i protocolli basati su XML durante la scrittura di comunicazioni tra processi che inviano grandi quantità di dati (ad es. Grandi richieste / risposte o frequenti piccole quantità di dati). Il costo dell'analisi XML è in genere ordini di grandezza superiori a formati di filo più ottimizzati (ad es. ASN.1).

Per le applicazioni di controllo a basso volume, la semplicità di XML-RPC dovrebbe superare i costi delle prestazioni. Per comunicazioni di dati ad alto volume potrebbe essere meglio utilizzare un protocollo di filo più efficiente.