Newsgroup: it.comp.os.linux.sys
Titolo: Analisi di protocollo

E due...
sono impelagato in una analisi di protocollo per verificare se i tempi di
risposta di un determinato applicativo (web) siano lenti per via delle
ritrasmissioni spesso presenti (i client sono tutti palmari RF) oppure per
via della lentezza dell'applicativo nell'interpretare le richieste e
fornire le risposte.
Il procedimento che uso consiste nell'identificare ogni sessione e
considerare:
Tempo totale per la transazione come il tempo che intercorre dal SYN
iniziale al primo FIN di chiusura.
Tempo di elaborazione come il tempo che intercorre tra il passaggio
dell'ack del segmento contenente la domanda al primo segmento che contiene
la risposta.
insomma, le mie comunicazioni tipo hanno questa forma
SYN	->	----------------------+
SYN/ACK	<-	                      |
ACK	->	                      |Tempo totale
PSH	->	                      |
ACK	<-	-+ Tempo di           |
PSH	<-	-+ elaborazione       |
ACK	->	                      |
FIN	<-	----------------------+
ACK	->
FIN	->
ACK	<-
Vorrei un output tipo:
numero sessione		tempo totale	tempo elaborazione	num. ritrasmissioni
Ho pensato di fare uno script in awk, ma la cosa è abbastanza complessa
(identificare univocamente le sessioni, identificare ritrasmissioni,
ecc...).
Dato che l'attività è indubbiamente ripetitiva e pallosetta, qualcuno sa
indicare qualcosa di pronto ( il dump è un binario cacciato fuori da
tcpdump, ovviamente...)?
Ciaotutti
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Skull says:
Stop VeriSign. Go to 
http://www.whois.sc/verisign-dns/
* The most stupid thing since Microsoft Network... <g> *

 considerare:
Scusa, ma volgio intervenire nel merito della tua analisi. Scusami ma mi
pare un po' strano l'approccio. Mi sembra difficile partendo da quei
presupposti poter capire se i tempi vengono persi cosi' o coli'.
Mi spiego: secondo me quei valori considerati in assoluto saranno poco
esplicativi e insignificanti.
Secondo me ... a prescindere da tcpdump e da awk dovresti poter fare dei
confronti tra valori con usando diverse applicazioni e/o la stessa
applicazione su differenti situazioni ambientali di rete.
-- 
Ciao,
Massimiliano Adamo
* * * *
Linux make Oracle unbreakable

 applicazione su differenti situazioni ambientali di rete.
Il che fornisce ulteriori dati empirici, ma non mi dà alcuna reale
conferma di *dove* viene perso il tempo, che invece è quello che
interessa a me.
In ogni caso, poco mi interessa di testarlo in altri ambienti, con reti
ethernet piuttosto che token al posto della 802.11 su cui lavorano.
Quell'applicativo è fatto per lavorare lì, con quei client: sono terminali
industriali, che vendiamo noi e che montano un browser *fatto* da noi.
So fino alla nausea come si comportano (anzi, a forza di dumpare e
analizzare, ho trovato anche un bug dello stack di windows 2000, fai te...)
oltretutto, la rete dove c'è 'sta roba è fisicamente a 350 Km da me...
Ciao :-)


 Orpo... vorrei sapere perchč, perň... :-/
no nono lo so. E' una mia idea/interpretazione. L'idea che dai
millisecondi e dai microsecondi persi dai pacchetti si possa riuscire a
capire la performance globale di un'applicazione non mi convince.
sbaglio? 
Non lo so. Resta comunque un quesito interessante.


 Non lo so. Resta comunque un quesito interessante.
'spe.. forse non è chiaro l'intorno... :-)
Io l'applicazione la conosco (come dicevo, la facciamo noi...), comprese
le sue performances (sulle quali, in effetti, qualcosa da ridire c'è...).
Solo che in una installazione, notano tempi di risposta dilatati.
In questa installazione, non siamo stati noi a fare il layout del
posizionamento degli Access Point, ma un'altra azienda scelta dal cliente.
Gli AP installati da costoro sono metà di quelli preventivati da noi in
prima istanza (oltre al fatto che io, di una azienda che ha bisogno di
"chiamare il sistemista dalla sede centrale" per inserire una dannata wep
key, non è che mi fidi molto...).
L'ambaradan di cui sopra mi serve proprio per dare visibilità al cliente,
di dove effettivamente il tempo viene perso, ovvero, che non è
l'applicazione ad essere lenta (almeno non *così* lenta...), ma di come ci
sia un rapporto diretto tra le transazioni più lente e i pacchetti persi
dalla tratta radio...
Ecco perchè devo lavorare su dati reali.
'nsomma, l'attività non è di profiling dell'applicazione... :-)
Ciao...


 posizionamento degli Access Point, ma un'altra azienda scelta dal cliente.
Accesso Point? E' una wireless?
aaahhh. Ora capisco. Sono reti poco performanti ed e' facile dimostrare
latenze alte. .... ma ... se vi replicano: "tutto il resto funziona bene"


 bene"
Gli AP in questione sono in dei magazzini, e ci lavorano terminali
industriali.
Vengono usati solo con quelli :-P
Anche se cmq fosse questo il caso, è problema noto che quei terminali
hanno (per questioni di batteria, principalmente) una capacità trasmissiva
più bassa di altri apparati come laptop ecc.
Quindi non è una obiezione valida :-)
Noi lo sappiamo e i nostri dimensionamenti della copertura radio prendono
in considerazione anche questo. Se poi il cliente preferisce andare a
fornirsi da qualcun altro perchè glieli fa pagare meno e perchè gli
garantisce che gliene bastano meno, liberissimo, ma non sono fatti miei se
poi la copertura non è sufficiente...
E a me questo basta dimostrare...
'ao ;-)
