La comunicazione bidirezionale con 1 presa - come affrontare le collisioni?

Question

Ho un app. che consiste di "Manager" e "lavoratore". Attualmente, il lavoratore inizia sempre la connessione, dice qualcosa al gestore, e il gestore invierà la risposta.

Dal momento che c'è un sacco di comunicazione tra il Gestore e il lavoratore, Sto pensando di avere una presa aperta tra i due e fare la comunicazione. Sto anche sperando di avviare l'interazione da entrambi i lati - che consente al gestore di dire qualcosa al lavoratore ogni volta che vuole.

Comunque, sto un po 'confuso su come trattare con "collisioni". Dire, il manager decide di dire qualcosa al lavoratore, e allo stesso tempo il lavoratore decide di dire qualcosa al gestore. Cosa accadrà? Come dovrebbe essere gestita questa situazione?

P.S. Ho intenzione di utilizzare Netty per l'effettiva attuazione.

Answer 1

"Sto anche sperando di avviare l'interazione da entrambi i lati -. Che consente al gestore di dire qualcosa al lavoratore ogni volta che vuole"

Risposta semplice. Non farlo.

Imparare dai protocolli esistenti: Avere un client e un server. Le cose funzionino bene. Lavoratore può essere il server e il Manager può essere un client. Manager può fare numerose richieste. risponde dei lavoratori alle richieste arrivano.

peer-to-peer può essere complessa senza alcun valore reale per la complessità.

Answer 2

mi piacerebbe andare per un canale bidirezionale persistenti tra server e client.

Se tutto quello che avrete è una del server e una del cliente, allora non c'è problema di collisione ... Se il server accetta una connessione, sa che è il cliente e viceversa. Entrambi può leggere e scrivere sulla stessa presa.

Ora, se si dispone di più client e le vostre esigenze di server per inviare una richiesta specificamente per cliente X, allora avete bisogno di handshake

Quando si avvia un client, si connette al server. Una volta che questa connessione è stabilita, il client si identifica come essendo X client (il messaggio di handshake). Il server ora sa che ha un socket aperto per X client e ogni volta che ha bisogno di inviare un messaggio a X client, si riutilizza che presa.

Beato te, ho appena scritto un tutorial (progetto di esempio incluso) su questo problema preciso. Utilizzando Netty! :)

Ecco il link: http: // bruno. linker45.eu/2010/07/15/handshaking-tutorial-with-netty/

Si noti che in questa soluzione, il server non tentare di connettersi al client. E 'sempre il cliente che si connette al server. Se stavate pensando di aprire un socket ogni volta che si voleva inviare un messaggio, si dovrebbe riconsiderare le connessioni persistenti in quanto evitano il sovraccarico di connessione stabilimento, di conseguenza, accelerando la velocità di trasferimento dei dati N volte.

Answer 3

Credo che hai bisogno di leggere su socket ....

non si ha realmente ottenere questi tipi di problemi .... Altro che come gestire responsabilmente sia ricezione e l'invio, in genere questo viene fatto attraverso la filettatura tue comunicazione ... a seconda dell'applicazione si può prendere un certo numero di approcci a questo.

Answer 4

la correttezza dei link per il tutorial Handshake / Netty menzionato nella risposta di brunodecarvalho è http://bruno.factor45.org/blag/2010/07/15/handshaking-tutorial-with-netty/
Vorrei aggiungere questo come un commento alla sua domanda, ma non ho il minimo reputazione necessaria per farlo.

Answer 5

Se avete voglia di reinventare la ruota e non si desidera utilizzare il middleware ...

Progettare il protocollo in modo che le risposte dell'altro pari alle vostre richieste sono sempre facilmente distinguibili dalle richieste da l'altro peer. Quindi, scegliere con cura la vostra strategia di rete di I / O. Qualunque sia il codice è responsabile per la lettura dalla presa deve prima determinare se i dati in entrata è una risposta ai dati che è stato inviato fuori, o se si tratta di una nuova richiesta dal peer (guardando intestazione del dati, e se hai emesso una richiesta recentemente). Inoltre, è necessario mantenere la corretta messa in coda in modo che quando si inviano le risposte alle richieste del pari è correttamente separato da nuove richieste si emette.