Proxying i multitons

0

Ho un'app che funziona come un server TCP e accetta connessioni multiple. Ogni connessione viene effettuata da un dispositivo distinto, con un ID univoco (l'ID viene segnalato dal dispositivo in due messaggi diversi in base al suo protocollo, ma ciò è meno importante).

In questo momento, ogni volta che viene stabilita una connessione, la mia app crea un nuovo elenco di parser per un gruppo di messaggi che il dispositivo può inviare, ma a quel punto non sa ancora quale dispositivo è stato connesso. Il problema è che diversi messaggi possono essere analizzati prima che venga stabilita l'identità del dispositivo. Poiché i dispositivi possono disconnettersi e riconnettersi durante la vita dell'app, ci sono oggetti longevo (statistiche del dispositivo e vari altri dati) che non dovrebbero essere scartati ogni volta che un dispositivo si disconnette e quindi devono essere ricollegati come consumatori della pipeline del parser una volta che l'ID del dispositivo è stabilito. In alternativa, se un dispositivo non è mai stato collegato in precedenza, le sue nuove istanze diventeranno longevi.

Qualcuno ha un'idea generale di come dovrebbe essere riorganizzata questa applicazione? Ad esempio, una idea era quella di avvolgere gli oggetti a lungo termine in proxy e quindi avere la possibilità di cambiare l'implementazione sottostante con un'altra istanza, una volta collegato un nuovo dispositivo. Per renderlo più chiaro, questi oggetti non sono singleton pubblici (multitoni), ma c'è ovviamente un dizionario (per ID) da qualche parte nel livello aziendale per tenere traccia dei dati per dispositivo.

Tutto ciò sembra inutilmente complesso, ma il codice (come sempre) ovviamente si è evoluto nel tempo e ora sento che non riesco a vedere la foresta tra gli alberi.

    
posta Groo 19.07.2011 - 11:56
fonte

1 risposta

1

Bene, penso che tu debba distinguere chiaramente ed esplicitamente due cose: un client e una connessione .

Una connessione è qualcosa di potenzialmente breve. Viene aperto (e quindi istanziato), viene chiuso (e quindi eliminato). Può o non può essere associato a un cliente. Può usare questo protocollo o quel protocollo, questo o quel livello di trasporto, ecc.

Un cliente (quello che chiami dispositivo) è piuttosto longevo. Potresti anche desiderare che sia persistente. Chissà. In ogni caso contiene quelle "statistiche e vari altri dati".

Da questo ragionamento, i parser e simili appartengono alla connessione, piuttosto che al client. Alla fine tutti questi dettagli su come i messaggi raggiungono il tuo punto finale della connessione dovrebbero essere incapsulati in un oggetto che rappresenta il protocollo che appartiene a quella connessione.

Una volta che il tuo endpoint di una connessione riceve dati di identificazione, dovrebbe chiedere a un gestore clienti di fornire un oggetto client compatibile con cui comunicare. Le specifiche di come funziona il manager sono irrilevanti per il design generale. Gli dai un ID, ottieni un cliente. Il gestore clienti decide se è necessario creare un nuovo oggetto o se ne esiste uno o se è necessario crearlo dal livello di persistenza o da qualsiasi altra cosa.
Una volta che la connessione ha il suo client, può registrarsi e inviare tutti i tipi di informazioni ad esso, o il cliente in cambio può guardare gli eventi sulla connessione, ecc. Una volta che una connessione è chiusa, deve annullare la registrazione dal suo client (supponendo che ne abbia uno) e liberare il suo protocollo.

    
risposta data 19.07.2011 - 12:37
fonte

Leggi altre domande sui tag