Recupero di errori senza impegnare una comunicazione eccessiva quando si utilizzano prese

Question

Recupero di errori senza impegnare una comunicazione eccessiva quando si utilizzano prese

#1 da (3 voti)

1

Attualmente sto scrivendo un programma che comunica con un server su socket TCP. Inizialmente avevo pianificato che la comunicazione includesse un messaggio che confermasse la comunicazione di successo alla fine della corrispondenza. Il server e il client attendono una risposta dopo ogni comunicazione, a seconda di chi ha avviato il messaggio. Tuttavia, in seguito ho letto che un primo passo nell'ottimizzazione delle comunicazioni socket sta rimuovendo la corrispondenza non necessaria, poiché ogni messaggio inviato ha un piccolo sovraccarico in attesa di una risposta. Così ho deciso di rimuovere i messaggi di conferma.

Tuttavia, quei messaggi di conferma erano il mio modo più semplice di inserire messaggi di errore. Qual è il metodo migliore per inviare errori su un sistema Socket di questo tipo? Sto cercando di ottimizzare prematuramente?

Il server si troverebbe su un dispositivo remoto con un ping potenzialmente alto. Le richieste generalmente arrivano in grandi gruppi, ma ogni richiesta è in realtà individuale e può essere chiamata fuori dal contesto. Dipende totalmente dall'interazione dell'utente. Pertanto, non posso sapere quante richieste saranno fatte. Non è facile per il cliente capire quando l'utente ha finito di richiedere informazioni. Avevo pensato di inviare un singolo metodo di conferma dopo un gruppo di richieste, ma la frase precedente lo rende impossibile.

Attualmente sto usando Java per entrambe le estremità di questo programma.

error-handling java sockets optimization

posta DonyorM 22.02.2016 - 12:47

fonte

1 risposta

Leggi altre domande sui tag error-handling java sockets optimization

Come si dovrebbe implementare l'iniezione delle dipendenze per un client di geocoding che aggrega diverse implementazioni dei provider di coordinate? In Go, perché append () non è implementato come metodo, ma come funzione?

score 3 · Answer 1

Ci sono quattro modi per approcciare le comunicazioni client-server:

Sincrono: ogni richiesta riceve una risposta di qualche forma.
Con questo approccio, il client attende una risposta dopo ogni richiesta e si aspetta che ogni richiesta abbia una risposta. Ciò introduce ritardi perché il client (o il server) potrebbe potenzialmente fare qualcos'altro mentre attende una risposta. Ma se il cliente ha bisogno della risposta, non ha alternative. Un esempio di questo stile è HTTP 1.x.
Batch sincrono: richieste multiple soddisfatte da una singola risposta.
Se il client può bufferizzare i messaggi, in modo trasparente in un buffer di rete o esplicitamente, è più efficiente inviarli tutti in una volta e attendere una singola risposta. Un sacco di protocolli di messaggistica ad alte prestazioni funzionano in questo modo.
Asincrono: il client invia senza attendere la risposta; server risponde come necessario.
Questo è probabilmente il modo più efficace per comunicare, almeno in un mondo perfetto. È come TCP funziona sotto le copertine, come funziona il protocollo X Window e quanti giochi online funzionano. Tuttavia , funziona meglio se la richiesta e la risposta sono completamente indipendenti: ad esempio, SSH invia un carattere durante la digitazione e visualizza i caratteri che riceve. Se devi abbinare le risposte alle richieste, allora ti imbatti in tutta una serie di potenziali problemi, che vanno dai messaggi fuori ordine alla mancanza di memoria.
Unidirezionale (aka publish-subscribe): il client invia un messaggio, non si aspetta una risposta.
Personalmente, vedo questo come una variante della comunicazione asincrona, ma ho pensato che meritasse di essere richiamato.

Nel tuo caso, penso che tu sia bloccato con la comunicazione sincrona: non sai quanti messaggi potresti inviare, quindi devi davvero aspettare ogni risposta.

È possibile passare a una modalità batch inviando un messaggio di flag alla fine del normale flusso di messaggi. La risposta del server al messaggio flag con una risposta generale positiva o negativa.

Il rovescio della medaglia è che il client tenta di inviare tutti i messaggi prima di attendere una risposta. A seconda di quanto sono grandi i messaggi, questo potrebbe essere uno spreco. D'altra parte, il server potrebbe scegliere di inviare immediatamente la risposta all'errore e il client potrebbe dedicare un secondo thread all'ascolto (che ti avvicina all'asincrono).

Ma probabilmente scoprirai che non ottieni molto throughput aumentando la complessità, ed è molto meglio essere più che veloci.