Newsgroup: it.discussioni.ingegneria
Titolo: Aspetti trasmissivi in architetture client-server.

Buongiorno a tutto il ng,
spero innanzitutto di non essere off-topic...in tal caso, mi scuso 
vivamente.
Dunque, veniamo all'argomento... in una architettura client-server, a 
prescindere dal linguaggio in cui è realizzata e dal tipo di client (web o 
meno), è del tutto evidente che lo schema di funzionamento - a livello molto 
grossolano - è di questo tipo:
- il client invia i dati da elaborare al server;
- il server elabora i dati e fornisce un risultato in output;
- il client riceve i dati dal server e li presenta all'utente.
Ora, il tempo di elaborazione dei dati, una volta ricevuti, da parte del 
server è di fatto indipendente dalla tipologia di rete trasmissiva tramite 
la quale l'elaborazione avviene: il client può essere in LAN con il server o 
ad essere connesso ad esso in WAN, ma ciò non influisce sul tempo di 
elaborazione 'pura' degli stessi. Invece, come è ovvio, la tipologia di rete 
sottostante è decisamente influente sul tempo di risposta complessivo del 
sistema.
Consideriamo una certa operazione O che il client deve eseguire. Per 
eseguire O, il client necessita di recuperare, tramite il server remoto, una 
serie di dati o informazioni di un certo tipo. Per la natura dell'operazione 
stessa, è possibile seguire due alternative:
- il client invia al server in un'unica chiamata tutta l'informazione di 
input e il server fornisce tutta l'informazione di output in ritorno;
- il client esegue una serie di chiamate successive al server, inviando e 
ricevendo di volta in volta solo l'informazione minima necessaria al 
completamento del singolo step di O.
Supponendo che il payload trasmissivo sia pressocchè identico in entrambi i 
casi, e che in entrambi i casi il quantitativo di dati non sia banale: 
secondo il vostro parere, quale strategia conviene adottare ? Singola 
richiesta o richieste multiple ?
In generale come best practice viene consigliato l'invio di un'unica 
richiesta per evitare l'overhead di rete: mi viene da chiedere, però, quale 
ne sia  la ragione, considerando che le reti LAN o WAN ormai sono ad ampia 
banda. Se T è il tempo di trasmissione per un payload P, qual'è l'andamento 
e il comportamento di T ? Immagino che non sia lineare, altrimenti si 
avrebbe T(P) = n*T(P/n) per cui sarebbe indifferente eseguire una richiesta 
singola o tante piccole richieste.
Qualcuno sa illuminarmi, anche con qualche link ?
Grazie a tutti ! 

 singola o tante piccole richieste.
Vado a braccio:
SINGOLA RICHIESTA
--------------------------
Ttot_1 = Trichiesta + Ttrasmissione_payload + Trisposta
N RICHIESTE
----------------
Ttot_n = n * (Trichiesta + Ttrasmissione_payload/n + Trisposta)
Segue che:  Ttot_n = Ttot_1 + (n-1) * Trichiesta  + (n-1) * Trisposta
da cui: Ttot_n > Ttot_1
--
Fabrizio

 Ttot_n = n * (Trichiesta + Ttrasmissione_payload/n + Trisposta)
Mumble, questa relazione andrebbe riscritta
Ttot_n = n * (Trichiesta + Ttrasmissione_payload/n) + Trisposta
assumendo che il tempo totale di elaborazione 'integrale' o 'a pezzi' sia lo 
stesso; inoltre, equivale a supporre che davvero il comportamento su rete 
sia lineare, per cui valga la relazione T(n*x) = nT(x).. cosa che non so se 
sia vera o falsa e che appunto vorrei approfondire...
Grazie ancora ! 

Spezzettare la transazione in piccole parti si porta dietro i ritardi di 
propagazione Tp, che sono 2*Tp per transazione. Se si parla di 
un'applicazione su internet possono anche essere centinaia di 
millisecondi, che moltiplicati per un numero elevato a piacere di 
sotto-transazioni client-server portano ad un deteriorare delle prestazioni.
La situazione peggiora ulteriormente se si pensa che su un collegamento 
internet ci sono pure spesso problemi di jitter, il che rende meno 
prevedibili nel tempo le prestazioni dell'applicazione distribuita. 
Inoltre su internet ï¿œ pure piï¿œ facile perdere pacchetti e molto spesso 
le linee di almeno una delle due parti (spesso il client) sono asimmetriche.
Per questo schemi di comunicazione molto chiacchieroni come il CIFS (il 
file sharing su rete di windows tanto per intenderci - che per ogni 
operazione genera un elvato quantitativo di sotto-operazioni che 
richiedono scambi multipli client-server) funzionano bene in locale dove 
la capacitï¿œ, simmetrica oltretutto, ï¿œ elevata e le latenze basse, anche 
<1ms, ma male su internet, specialmente per le operazioni di servizio 
tipo lettura delle directory, creazione/spostamento/cancellazione file, ecc.
Avere stream unici troppo grossi tuttavia ha comunque i suoi svantaggi, 
per cui poi in realtï¿œ alla fine la scelta viene fatta a partire dal tipo 
di payload che si vuole trasportare e dai vincoli che l'applicazione impone.


 impone.
Ti ringrazio per l'esauriente spiegazione.