Differenza tra modello proattivo e modello sincrono nel server Web

Question

Nel modello sincrono, quando un client si connette al server, sia il client che il server devono sincronizzarsi l'uno con l'altro per terminare alcune operazioni.

Nel frattempo, il modello asincrono consente al client e al server di funzionare separati e indipendenti. Il client invia una richiesta per stabilire una connessione e fare qualcosa. Mentre il server sta elaborando la richiesta, il client può fare qualcos'altro. Al termine di un'operazione, l'evento di completamento viene inserito in una coda in un Demultiplexer di eventi, in attesa che un Proactor (come HTTP Handler) invii la richiesta e invochi un Completion Handler (sul client). I termini sono usati come in boost :: asio document The Proactor Design Pattern: Concurrency Without Threads.

Operando in questo modo, il modello asincrono può accettare connessioni simultanee senza dover creare un thread per connessione, quindi migliorare le prestazioni generali. Per ottenere lo stesso effetto del modello asincrono, il primo modello (sincrono) deve essere multithread. Per ulteriori dettagli, fare riferimento a: Proactor Pattern (In realtà, apprendo lo schema del proactor utilizzato per il modello asincrono da quel documento, che contiene una descrizione su un tipico server Web di I/O sincrono).

La mia comprensione in materia è corretta? In tal caso, il che significa che il server asincrono può accettare la richiesta e restituire i risultati in modo asincrono (la prima richiesta di connessione al servizio sul server web non deve essere la prima a rispondere)? In sostanza, il modello asincrono non utilizza il threading (o il threading viene utilizzato in singoli componenti, come nel componente Proxy, Multiplexer eventi asincrono (boost :: asio document), non creando un intero stack di applicazioni client-server, che è descritto nel modello multi-threaded nel documento Pattern Proactor, sezione 2.2 - Trappole e insidie ​​comuni dei modelli di concorrenza convenzionali. 2.2 - .

Answer 1

Il modello Proactor presuppone la suddivisione del processo di sessione di rete in attività secondarie come: risoluzione del nome host, accettazione o connessione, lettura o scrittura di alcune parti di informazioni, chiusura della connessione e possibilità di passare da sottotask a sessioni diverse. Mentre il modello Reactor vede il processo di sessione di rete come un (quasi) singolo compito.

I vantaggi Proactor assoluti:

• La performance è amplificato a causa del compito "esternalizzazione". Ad esempio, puoi inviare una richiesta di risoluzione al DNS e attendere 5 minuti per la risposta senza fare nulla (Reactor) - oppure puoi fare altre cose mentre aspetti (Proactor).

Gli svantaggi Proactor assoluti:

• La prestazione è diminuita a causa della commutazione compito, il che significa che per la singola sessione si esegue più codice (Proactor) del dovuto (reattore).

Ma le prestazioni complessive di solito sono misurate in un numero di clienti "soddisfatti" per periodo di tempo. Quindi, i vantaggi di Proactor vs. Reactor dipendono dalla situazione. Ecco alcuni esempi

1. server HTTP. Il cliente vuole vedere qualcosa nella sua finestra del browser. Non ha bisogno di aspettare prima che l'intera pagina sia caricata per vedere i primi pezzi di testo. Il Proactor è efficace, poiché il caricamento parziale della pagina è più veloce dell'intero caricamento della pagina. L'intera pagina viene caricata nello stesso momento del modello Reactor.

2. Server di giochi a bassa latenza. Il cliente desidera ottenere il risultato completo del suo comando il più rapidamente possibile. Il Reactor è efficace, dal momento che non ci sono sottoattività come lettura parziale o scrittura - il cliente non vedrà nulla finché non leggerà la risposta completa. Quindi, il Reactor non eseguirà ulteriori switch tra le sottoattività e in ogni momento è garantito che alcuni client ottengano dei progressi sul suo comando, mentre Proactor forzerà tutti i client ad attendere l'un l'altro il tempo imprevedibile.

Il multithreading può fornire un'accelerazione lineare in entrambi i casi.