Modelli di progettazione per server di messaggistica multi-thread

Question

Modelli di progettazione per server di messaggistica multi-thread

#1 da (3 voti)

5

Sto progettando un server di messaggistica istantanea come esercizio personale per migliorare la mia comprensione e l'applicazione di modelli di multi-threading e di progettazione in Java. Sto ancora progettando, non c'è ancora il codice.

Il mio obiettivo è avere un server che dovrebbe fare un uso efficace di una scatola multi-CPU. Mi piacerebbe che il server fosse distribuibile su più caselle, ma mi chiedo se è in esecuzione prima che io possa camminare.

I miei pensieri iniziali sono:

ClientConnectionManager ha ServerSocket oggetto che accetta costantemente client Socket connessioni.
ClientConnectionManager ha un pool di thread che genera un nuovo oggetto ClientProxy quando viene accettata una connessione socket client, consegnando l'oggetto Socket del client.
Gli oggetti ClientProxy rappresentano l'app client e gestiscono l'invio / la ricezione di messaggi attraverso lo Socket stream.

È corretto che solo un ServerSocket possa legarsi a una Porta? Suppongo che non ci sia modo di avere un pool di oggetti che accettano connessioni Socket?

Ho due idee per il passaggio di messaggi tra ClientProxy oggetti. O direttamente tra ClientProxy oggetti che sono "amici" o tramite un oggetto centrale "Exchange", o meglio ancora, pool di oggetti.

Quali sono i pro / contro dei due approcci? Exchange si presta meglio a un'app distribuita?

I modelli Observer e Mediator, rispettivamente, sarebbero appropriati?

design-patterns multithreading distributed-computing observer-pattern

posta retrodev 15.09.2013 - 14:53

fonte

1 risposta

Leggi altre domande sui tag design-patterns multithreading distributed-computing observer-pattern

Passare un contesto con un'iniezione di dipendenza che algoritmi di ordinamento utilizza OrderBy

score 3 · Accepted Answer

Is it correct that only one ServerSocket may bind to a Port? I take it there's no way to have a pool of objects accepting Socket connections?

Una corretta. Solo una cosa può legarsi a una determinata porta su una data interfaccia di rete alla volta. Ogni volta che viene ricevuta una connessione, viene creato automaticamente un nuovo socket per il client su una porta differita / indirizzata internamente. Questo è il modo in cui un singolo listener può generare un numero qualsiasi di gestori client senza attendere che quello precedente si disconnetta.

I have two ideas for passing messages between ClientProxy objects. Either directly between ClientProxy objects that are "buddies" or via a central "Exchange" object, or better yet, pool of objects.

Puoi fare in modo che i client ricevano un proxy nelle code dei messaggi dei loro amici ogni volta che gli amici arrivano online. Possono quindi accodare direttamente i messaggi tra loro, evitando la necessità di uno scambio centralizzato. Il server manterrà un riferimento a tutti i suoi client online e informerà le parti interessate delle connessioni / disconnessioni dei loro amici tramite la coda.

Ridimensionare questo per riempire una singola casella diventerebbe questione di aggiungere interfacce di rete (o usare un intervallo di porte sull'unica interfaccia). Il ridimensionamento su più box richiederebbe la sincronizzazione dei server / i proxy delle code di passaggio "and-fro willy nilly".