opencdn-devel-it Mailing List for OpenCDN (Page 3)
Brought to you by:
aalef
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(31) |
Feb
(51) |
Mar
(15) |
Apr
(23) |
May
(16) |
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(3) |
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alessandro F. <aa...@li...> - 2005-05-01 20:46:50
|
Credo che la modifica con errore da parte mia, sia dovuta alla mia scarsa (se non nulla) conoscenza del funzionamento di Helix. Se la "modifica all'indietro" che suggerisci, puo' risolversi semplicemente sostituendo il codice modificato, con quello che risale a prima della modifica, puoi farlo tu, che almeno puoi verificare se le modifiche risultano gradite ad Helix. Se puoi, prova quindi anche con Dummy, e questo dovrebbe provare che andra' poi bene anche per Darwin. Considera infatti che nella infrastruttura di test, mantengo disabilitata l'autenticazione RTSP, in modo da avere qualche chance di debug in piu'. al momento, mi sento ancora abbastanza lontano da OpenCDN, da temere di fare casini se tocco qualcosa. a presto Ale Il giorno ven, 29-04-2005 alle 16:24 +0200, Massimo Aghemo ha scritto: > Ho fatto qualche prova con la attuale versione su CVS, prima di > integrare le modifiche che ho apportato ad Helix.pm e mi sono accorto > di un problema che nella 0.7.1 non c'era: > quando si fa partire un nodo, il primo relay da esso creato non avra' > le credenziali impostate correttamente. Dopo qualche ora di > tribolazione sono riuscito a capire che cio' e' dovuto al fatto che > quando viene invocata in NodeLib.pm per la prima volta la funzione > do_relay la variabile RTSPpassword non e' ancora stata impostata, > poiche' non e' ancora stata invocata set_RTSP_credentials, dove cio' > avviene. > Allora mi sono chiesto: perche' mai la chiamata a > set_RTSP_credentials e' stata spostata dopo quella a do_relay? > Ho trovato la risposta in questo commit >=20 > ++++++++++++++++++++++++++++++++ > Update of /cvsroot/opencdn/oCDN/lib > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29282/lib >=20 > Modified Files: > Helix.pm NodeLib.pm=20 > Log Message: > Agreeing with Massimo Aghemo from Tilab, the call to=20 > set_RTSP_credentials in Nodelib:Transit has moved > after TR node determination. This avoids to set and > reset them immediately after, if node is a LH. >=20 > ++++++++++++++++++++++++++++++++ >=20 >=20 > Si tratta di una modifica che avevo chiesto io stesso ad Alessandro > per risolvere un problema di scarsa rilevanza, senza valutarne i > pesanti effetti collaterali. >=20 > Alessandro, potresti gentilmente ripristinare il comportamento > precedente? > Se non hai tempo, posso provare a farlo io, ma non vorrei creare > altri problemi. >=20 > Saluti, > Massimo >=20 >=20 > =09 > ___________________________________=20 > Nuovo Yahoo! Messenger: E' molto pi=C3=B9 divertente: Audibles, Avatar,= Webcam, Giochi, Rubrica=E2=80=A6 Scaricalo ora!=20 > http://it.messenger.yahoo.it >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Tell us your software development plans! > Take this survey and enter to win a one-year sub to SourceForge.net > Plus IDC's 2005 look-ahead and a copy of this survey > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=3D105hix > _______________________________________________ > Opencdn-devel-it mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opencdn-devel-it --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Alessandro F. <aa...@li...> - 2005-05-01 20:25:31
|
Scusatemi se accumulo ritardo nelle risposte, ma ancora non mi sento "a pieni giri".. anzi ho la sensazione che mi ci vorra' ancora un po :-( Il giorno gio, 28-04-2005 alle 12:10 +0200, Pierluigi Vittori ha scritto: > Ho lavorato in questi giorni al resto delle modifiche e aggiunte da far= e per la=20 > realizzazione della selezione del LH pi=F9 vicino tramite le ormai famo= se=20 > immaginette :-) >=20 > Dunque ho modificato il comportamento della funzione find_best che ades= so, se=20 > viene chiamata con un parametro nuovo (l'ip del client, appunto), mette= nella=20 > stringa del probe proprio questo dato, facendo capire al nodo sotto pro= be:=20 > "mandami il tempo di download del client". come "glielo fa capire" ? purtroppo il formato del probe e' nato in modo un po' "naif", spesso ho pensato che forse sarebbe stato il caso di formattarlo in XML, ma poi non l'ho mai fatto. Dato nel probe che c'e' gia' il "program" che puo' esserci o meno, non vorrei la presenza di un ulteriore parametro opzionale (l'IP del client) causasse problemi nel parsing.... > In base ai dati ricevuti, aspettando che siano tornate almeno tutte le = risposte=20 > dei nodi contenuti in una stessa FP, find_best decide qual'=E8 il LH pi= =F9 prossimo=20 > al client e lo restituisce al chiamante. >=20 > Per fare ci=F2, ho modificato anche il comportamento del figlio che ris= ponde al=20 > probe in modo che adesso, se nel probe in arrivo =E8 contenuto l'ip del= client di=20 > cui si vuole il tempo di download, il probe di risposta contiene anche = questo=20 > dato che, una volta "servito", viene cancellato dal DB_file. nel frattempo mi era anche venuto in mente, che potrebbe anche succedere che il probe arrivi prima ancora che sia stata scaricata del tutto l'immaginetta. A parte il caso di un viewer particolarmente frettoloso, ci sono poi i motori di ricerca, che "non guardano in faccia a nessuno". Credo che in tal caso, il comportamento piu' corretto sia di rispondere comunque subito al probe, senza restituire nessun tempo. E se chi ha spedito diversi probe, non riceve tempi da nessuno, deve comportarsi come prima che venisse introdotta questa nuova feature. Dico bene ? > Ho fatto un po' di prove tra il mio server e il portatile e devo dire c= he i=20 > risultati sono incoraggianti: viene addirittura selezionato il LH da cu= i il=20 > client ha scaricato l'immagine pi=F9 rapidamente! :-) juhuuu !! Il giorno ven, 29-04-2005 alle 12:14 +0200, Pierluigi Vittori ha scritto:=20 > Sempre nell'ambito del problema immaginette, ho modificato anche la pro= cedura=20 > di registrazione del nodo. giusto. > In particolare ho aggiunto una variabile $image_port al NodeConfig.pm e= questa=20 > variabile viene comunicata all'rrdm al momento della registrazione del = nodo. >=20 > Il valore di $image_port viene poi utilizzato dal nuovo metodo GetLH ch= e=20 > adesso, oltre a restituire l'indirizzo ip del nodo, manda anche la port= a su cui=20 > il demone http =E8 in ascolto per servire le immagini. per capire: quando il nodo si registra, manda anche la URL dell'immagine, del tipo http://indirizzodelnodo:portaperimmagine/nomeimmagine.gif ? e questa stessa url, viene restituita da GetLH, in modo che il portale la usi per generare la pagina da far vedere al viewer ? oppure http://indirizzodelnodo lo aggiunge il portale, mentre la registrazione contiene solo portaperimmagine/nomeimmagine.gif, che e' quello che sta scritto nel config ??? > Ovviamente, visto che messo mano a parecchi file e ho praticamente "dev= astato"=20 > il mio cvs locale, non vorrei fare altrettanto con quello di sourceforg= e, per=20 > cui, in attesa di ulteriori prove e verifiche, ancora non ho mandato su= alcuna=20 > modifica. temo solo il momento in cui verranno messe contemporaneamente sia le modifiche tue, che quelle di Massimo... per questo, penso che sarebbe meglio fare dei commit frequenti, con piccole modifiche ogni volta, cercando di lasciare il codice in uno stato sempre e comunque funzionante ! --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Massimo A. <m_a...@ya...> - 2005-04-29 14:24:43
|
Ho fatto qualche prova con la attuale versione su CVS, prima di integrare le modifiche che ho apportato ad Helix.pm e mi sono accorto di un problema che nella 0.7.1 non c'era: quando si fa partire un nodo, il primo relay da esso creato non avra' le credenziali impostate correttamente. Dopo qualche ora di tribolazione sono riuscito a capire che cio' e' dovuto al fatto che quando viene invocata in NodeLib.pm per la prima volta la funzione do_relay la variabile RTSPpassword non e' ancora stata impostata, poiche' non e' ancora stata invocata set_RTSP_credentials, dove cio' avviene. Allora mi sono chiesto: perche' mai la chiamata a set_RTSP_credentials e' stata spostata dopo quella a do_relay? Ho trovato la risposta in questo commit ++++++++++++++++++++++++++++++++ Update of /cvsroot/opencdn/oCDN/lib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29282/lib Modified Files: Helix.pm NodeLib.pm Log Message: Agreeing with Massimo Aghemo from Tilab, the call to set_RTSP_credentials in Nodelib:Transit has moved after TR node determination. This avoids to set and reset them immediately after, if node is a LH. ++++++++++++++++++++++++++++++++ Si tratta di una modifica che avevo chiesto io stesso ad Alessandro per risolvere un problema di scarsa rilevanza, senza valutarne i pesanti effetti collaterali. Alessandro, potresti gentilmente ripristinare il comportamento precedente? Se non hai tempo, posso provare a farlo io, ma non vorrei creare altri problemi. Saluti, Massimo ___________________________________ Nuovo Yahoo! Messenger: E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica Scaricalo ora! http://it.messenger.yahoo.it |
From: Pierluigi V. <or...@us...> - 2005-04-29 10:14:52
|
Sempre nell'ambito del problema immaginette, ho modificato anche la procedura di registrazione del nodo. In particolare ho aggiunto una variabile $image_port al NodeConfig.pm e questa variabile viene comunicata all'rrdm al momento della registrazione del nodo. Il valore di $image_port viene poi utilizzato dal nuovo metodo GetLH che adesso, oltre a restituire l'indirizzo ip del nodo, manda anche la porta su cui il demone http è in ascolto per servire le immagini. Ovviamente, visto che messo mano a parecchi file e ho praticamente "devastato" il mio cvs locale, non vorrei fare altrettanto con quello di sourceforge, per cui, in attesa di ulteriori prove e verifiche, ancora non ho mandato su alcuna modifica. Saluti, Pierluigi |
From: Alessandro F. <aa...@li...> - 2005-04-28 13:56:08
|
Massimo Aghemo ha scritto: > Ciao Alessandro, > ho quasi ultimato le modifiche a Helix.pm che superano il limite=20 > presente nella precedente versione dell'adaptation layer, che=20 > consentiva di configurare un unico relay per ciascun nodo (o meglio=20 > uno per i flussi live e uno per i caching).=20 urra' !!! > Devo ancora fare qualche test e poi se non emergono problemi far=F2 il=20 > commit della mia versione di Helix.pm. > Ho gi=E0 ripulito un po' il codice, risolvendo in particolare il=20 > problema dei tab (ora ho configurato vim in modo che il problema non=20 > si ripresenti in futuro).=20 Perfetto :-)) > Cercher=F2 di aggiungere ancora qualche riga di commento. > > Ho fatto aprire il firewall aziendale di Tilab cos=EC ora riesco ad=20 > utilizzare il sistema CVS (con ssh) di SourceForge. Ho seguito il tuo=20 > consiglio e ho installato lincvs: la prima impressione =E8 ottima. Devo= =20 > ancora leggermi un po' di documentazione su CVS, perch=E9 =E8 la prima=20 > volta che lo utilizzo e non vorrei fare casini: spero di riuscire ad=20 > aggiustarmi da solo, ma se dovessi avere dei dubbi posso chiederti=20 > qualche dritta?=20 sicuramente > In particolare ho un dubbio: facendo il checkout CVS ho scaricato la=20 > versione aggiornata del codice. Come faccio ora a inserire le mie=20 > modifiche? > - Sostituisco la mia versione a quella scaricata da CVS e poi faccio=20 > il commit? (nella mia versione ho gi=E0 integrato le ultime modifiche=20 > fatte da Marco rispetto all'ultimo rilascio).=20 se sei partito dall'ultima versione del cvs, puoi fare cosi'. tieni conto che rispetto a quelle di Marco, dovrebbero esserci anche=20 modifiche da parte mia, per far convivere sia Darwin che Helix nella=20 stessa macchina. Altrimenti, prova a fare un "diff" per scoprire le differenze tra la tua=20 versione e quella del cvs, ed allinea la tua versione con quella del cvs=20 per le parti in comune. Oppure invece di diff (testuale) con gli ultimi=20 rilasci di KDE c'e' un bellisimo "kompare" che mostra le differenze in=20 una forma grafica molto ben leggibile. se invece sostituisci direttamente la tua versione a quella del cvs, fai=20 il commit di quella, ed hai toccato delle linee che nel frattempo anche=20 qualcun altro aveva gia' modificato, il tuo commit e' respinto, e la tua=20 copia locale si modifica, evidenziando le linee in conflitto. Con un po'=20 di pazienza, si ri-edita ancora la versione locale, lasciando solo una=20 delle due alternative evidenziate, ed al commit successivo tutto va per=20 il meglio > - Devo per forza editare il file scaricato da lincvs integrando le mie=20 > modifiche?=20 in linea generale, lo sviluppo partecipato dovrebbe procedere cosi: 1 - si fa il checkout 2 - si fanno le modifiche 3 - si verifica che ancora funziona 4 - si fa il commit questo ogni giorno, anzi, piu' spesso si fa, (e piu' spesso lo fanno=20 tutti), minore e' la probabilita' di non entrare in conflitto con=20 modifiche altrui. Ovvero le modifiche vanno fatte "un passetto per=20 volta", anche ritornando piu' e piu' volte sui propri passi. Diverso e' il caso in cui si e' unici manutentori di una parte di=20 codice. In tal caso, ci si puo' permettere il lusso di lunghi intervalli=20 tra un commit e l'altro. E cosi' facendo, si semplifica anche il lavoro=20 della scrittura finale del "changelog" che "compilo" ad ogni rilascio,=20 mettendo assieme tutti i vari commenti parziali. > - D'ora in poi dovr=F2 lavorare sui file nella directory gestita da CVS= ?=20 si, e' proprio cosi. Oppure si sviluppa da un'altra parte, e poi si=20 riverifica in quella directory. Io trovo utile mantenere in quella=20 directory "altri" files e directory che non "aderiscono" al CVS, e=20 quindi non vengono condivise. ad esempio, ho i miei files di=20 configurazione, che ogni volta sostituisco a quelli del CVS, e=20 ripristino prima del commit. Ci vuole un po' di metodo, ma funziona. > Per il momento parteciper=F2 allo sviluppo a titolo personale e non per= =20 > conto [della ditta per cui lavoro XXX]: non siamo ancora riusciti a=20 > ottenere un commitment per lavorare su questo progetto e il fatto che=20 > io diffonda senza autorizzazione del software che ho sviluppato=20 > all'interno di XXX (anche se si tratta di un progetto opensource)=20 > potrebbe crearmi dei problemi. Si tratta soltanto di una situazione=20 > transitoria, perch=E9 a breve dovremmo fare delle demo sia all'interno=20 > di XXX (ne abbiamo gi=E0 fatta una qualche mese fa, per far partire la=20 > cosa) che presso YYY e ZZZ. Dall'esito delle demo decideremo poi come=20 > muoverci.=20 come vedi ti ho anonimizzato le corporation :-) facciamoci 1000 auguri=20 per tutte le demo allora! > A livello personale spero davvero che la cosa vada avanti perch=E9, in=20 > quanto convinto sostenitore dell'Open Source e felice utilizzatore di=20 > software libero (ormai anche per l'uso desktop sono riuscito ad=20 > abbandonare windows), ho sempre sognato di poter partecipare=20 > attivamente a un progetto Open Source.=20 mi pare la migliore cosa che potessi leggere :-) dal canto mio, posso solo aggiungere che i problemi familiari che mi=20 hanno preso negli ultimi tempi, si sono (infelicemente) conclusi=20 domenica sera, e quindi ora, a parte un certo mio stato direi=20 francamente confusionale, dovrei poter tornare a seguire gli sviluppi di=20 OpenCDN come un tempo. saluti a tutti |
From: Pierluigi V. <or...@us...> - 2005-04-28 10:10:49
|
Ho lavorato in questi giorni al resto delle modifiche e aggiunte da fare per la realizzazione della selezione del LH più vicino tramite le ormai famose immaginette :-) Dunque ho modificato il comportamento della funzione find_best che adesso, se viene chiamata con un parametro nuovo (l'ip del client, appunto), mette nella stringa del probe proprio questo dato, facendo capire al nodo sotto probe: "mandami il tempo di download del client". In base ai dati ricevuti, aspettando che siano tornate almeno tutte le risposte dei nodi contenuti in una stessa FP, find_best decide qual'è il LH più prossimo al client e lo restituisce al chiamante. Per fare ciò, ho modificato anche il comportamento del figlio che risponde al probe in modo che adesso, se nel probe in arrivo è contenuto l'ip del client di cui si vuole il tempo di download, il probe di risposta contiene anche questo dato che, una volta "servito", viene cancellato dal DB_file. Ho fatto un po' di prove tra il mio server e il portatile e devo dire che i risultati sono incoraggianti: viene addirittura selezionato il LH da cui il client ha scaricato l'immagine più rapidamente! :-) Saluti, Pierluigi |
From: Alessandro F. <aa...@li...> - 2005-04-22 20:17:12
|
premessa: non credo che avro' molte possibilita' di testare le modifiche di qui ai prossimi giorni... :( Il giorno ven, 22-04-2005 alle 11:09 +0200, Pierluigi Vittori ha scritto: > Ho completato la scrittura del codice (a parte gli inevitabili raffinam= enti che=20 > seguiranno) della prima fase della nuova procedura che prevede l'utiliz= zo delle=20 > immaginette da far scaricare al client dai LH candidati, per determinar= ne la=20 > distanza. Bene !! [...] > Quindi, alla fine di questa prima fase, il tempo di download dell'immag= ine da=20 > parte del cliente =E8 a disposizione del nodo che lo mander=E0 all'inte= rno del=20 > pacchetto udp di risposta al probe che arriver=E0 al momento di selezio= nare il=20 > migliore LH per quel dato cliente. ... e poi il tempo viene "cancellato" dopo che il probe e' stato "servito". > Una domanda: il nuovo metodo GetLH chiama la funzione Find_Nod per aver= e=20 > l'elenco dei LH candidati e surrogati ma Find_Nod restituisce anche la = lista=20 > dei TRansit candidati e surrogati. La domanda =E8: dobbiamo considerare= solo i LH=20 > oppure anche i TR? epperche' anche i transit ? per trovarne uno vicino al viewer ? ... diciamo che questo potrebbe essere l'oggetto di una speculazione futura.. ma per ora non ce ne preoccupiamo Invece, viene da pensare che FindNod potrebbe risparmiare del tempo, se restituisse solo lo stretto indispensabile. In effetti guardando il codice, sembra che la complessita' non e' piu' che doppia. In definitiva, per ora va bene lasciare FindNod cosi' com'e'. saluti --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Pierluigi V. <or...@us...> - 2005-04-22 09:10:02
|
Ho completato la scrittura del codice (a parte gli inevitabili raffinamenti che seguiranno) della prima fase della nuova procedura che prevede l'utilizzo delle immaginette da far scaricare al client dai LH candidati, per determinarne la distanza. Quindi adesso, accedendo alla home page del portale, viene individuato l'ip del client e questo ip, passato a un nuovo metodo xml-rpc dell'RRDM chiamato GetLH, serve a determinare i LH che possono servire l'ip del client. GetLH restituisce perciò alla home page del portale gli indirizzi dei LH, e questi indirizzi vengono formattati in altrettanti tag <img src=...> della pagina html. Le richieste delle immagini vengono fatte sulla porta 4405 dei nodi, dove adesso viene forkato ed è in ascolto un semplice demone http che serve tali richieste: il tempo di download dell'immagine viene cronometrato dal server http e viene salvato, tramite DB_file, in locale per il successivo utilizzo in risposta al probe. Quindi, alla fine di questa prima fase, il tempo di download dell'immagine da parte del cliente è a disposizione del nodo che lo manderà all'interno del pacchetto udp di risposta al probe che arriverà al momento di selezionare il migliore LH per quel dato cliente. Una domanda: il nuovo metodo GetLH chiama la funzione Find_Nod per avere l'elenco dei LH candidati e surrogati ma Find_Nod restituisce anche la lista dei TRansit candidati e surrogati. La domanda è: dobbiamo considerare solo i LH oppure anche i TR? Saluti, Pierluigi |
From: Alessandro F. <aa...@li...> - 2005-04-19 08:13:31
|
si tiene oggi a partire dalle 14:30, e' ospitata in slovenia, ma viene erogata anche in streaming. Io provero' a parteciapre da casa nonostante il video di gnomemeeting non sembri essere accettato, ma se ve la sentite, provate a collegarvi allo streaming presso http://vcg.arnes.si/tf-vvc, password: terena (occorre mplayer linkato con live!, ma non e' detto che basti). sara' una gran noia :-) Here are the conference details: - H.323 (IP) conference dialin (GDS) number: 0038601012121 (384 kbps, H.263/CIF, G.722/G.711, 27 reserved users). - Streaming (for WindowsMedia/QuickTime Player, H.263/G.711, Chat- enabled): http://vcg.arnes.si/tf-vvc password: terena - Contact e-mail: vid...@ar... Cheers, David -- David Vrtin, ARNES, Academic and Research Network of Slovenia Jamova 39, SI-1001 Ljubljana, Slovenia phone: +386 1 479 88 77, fax: +386 1 479 88 78, http://www.arnes.si -- Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Alessandro F. <aa...@li...> - 2005-04-14 22:45:45
|
Il gio, 2005-04-14 alle 15:52, Pierluigi Vittori ha scritto: > E' evidente, a questo punto, che =E8 assolutamente necessario che io mi= prenda un > fine settimana di riposo assoluto, avendo completamente fuso il cerve= llo... :-) succede nei migliori laboratori :-) > Ho rimesso a posto la chiamata a setsockopt e... FUNZIONA!!!!!!!!!!!!!!= !! grande :-))) --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Pierluigi V. <p.v...@ra...> - 2005-04-14 13:52:19
|
On 04/14/2005 11:12 AM, Alessandro Falaschi wrote: > chiedendo aiuto a google, mi sorge il dubbio che la sua chiamata a > setsockopt possa essere errata, ad esempio in > http://renaud.waldura.com/software/net-stats/net-stats-v3.4 trovo un > frammento che dice > > my $linger = pack('ii', 1, 120); # BSD struct linger > > setsockopt(CLIENT, SOL_SOCKET, SO_LINGER, $linger) > or warn "Cannot set socket option SO_LINGER: $!"; E' evidente, a questo punto, che è assolutamente necessario che io mi prenda un fine settimana di riposo assoluto, avendo completamente fuso il cervello... :-) Ho rimesso a posto la chiamata a setsockopt e... FUNZIONA!!!!!!!!!!!!!!!! Ho sniffato il comportamento del server e, finalmente, sembra fare esattamente quello che ci serve! Con il server sul mio computer e il client su labtel è andata così: Tempo (s) Direzione Azione 36.3275 avvio cronometro (sul server) 36.3277 S -> C invio pacchetto con i dati immagine 36.3864 C -> S ACK del 200 OK (inviato in precedenza) 36.4142 C -> S ACK del pacchetto immagine 36.4144 stop cronometro (sul server) quindi prendiamo esattamente un RTT, perché il FIN, ACK ecc. rimane fuori! In effetti, ho appena fatto diverse richieste, ne ho preso il tempo, le ho mediate e il risultato è stato un tempo medio di 111 ms. Ho subito fatto un ping (con una decina di pingate successive) e l'RTT medio che ne è venuto fuori è stato di 108 ms! Mi sento più leggero... :-) Saluti, Pierluigi |
From: Alessandro F. <aa...@li...> - 2005-04-14 09:10:52
|
Il mer, 2005-04-13 alle 13:49, Pierluigi Vittori ha scritto: > Ho appena fatto un test molto indicativo. > Sto usando una cosa del tipo > > setsockopt($c, SOL_SOCKET, SO_LINGER, 10); > ($s, $us) = gettimeofday; > $sent_bytes = send($c, $image, 0); > close $c; > ($s1, $us1) = gettimeofday; > > per cercare di rilevare il tempo di invio dell'immagine. > > Ho espressamente settato SO_LINGER per dire al socket di non chiudersi in > background nella speranza che close tornasse, appunto, dopo l'invio completo > dei dati o addirittura dopo l'ACK finale del client. > Manco per niente! :-( ... confesso di non essere "addentrissimo" nell'argomento, quindi mi piacerebbe capire meglio cosa stiamo usando. ho trovato qualcosa a riguardo di SO_LINGER in man 7 socket, ma quello e' c, mentre in man IO::Socket (che e' perl) si parla di "sockopt" e non di setsockopt. Ma dopo ulteriri analisi, vedo che sta in perldoc perlfunc. chiedendo aiuto a google, mi sorge il dubbio che la sua chiamata a setsockopt possa essere errata, ad esempio in http://renaud.waldura.com/software/net-stats/net-stats-v3.4 trovo un frammento che dice my $linger = pack('ii', 1, 120); # BSD struct linger setsockopt(CLIENT, SOL_SOCKET, SO_LINGER, $linger) or warn "Cannot set socket option SO_LINGER: $!"; e quindi sembra che il valore dell'opzione non sia un numero di secondi nudi e crudi, ma qualcosa di piu' evoluto. Questo forse trova riscontro nel fatto che man 7 socket riporta struct linger { int l_onoff; /* linger active */ int l_linger; /* how many seconds to linger for */ }; e quindi sembra che gli si debba passare sia un flag 0/1, sia il timeout. potrei non averci capito un tubo, ma ci proverei... -- Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Alessandro F. <aa...@li...> - 2005-04-14 08:11:03
|
Il mer, 2005-04-13 alle 15:52, Marco Volpino ha scritto: > > Ho realmente testato la cosa solo per Darwin e per Dummy, tra l'altro > > con l'autenticazione RTSP disabilitata per le Origin. Ora chiederei a > > Marco se puo' effettuare una serie di test per Helix, >=20 > Ho svolto a casa un p=F2 di test con Helix, e sembra che continui a > funzionare correttamente.=20 Bene ! > Tuttavia credo che si sia dimenticato di > importare la variabile '$ad_layer' in 'Origin.pm' e di esportarla > da 'OriginConfig', per consentire all'Origin di caricare lo strato > di adattamento nel caso in cui lo streaming server sorgente sia > coresidente. si pare che sia cosi'... anzi mi pare che l'ho fatto nelle directory "production", ma ho dimenticato di riportarlo nella versione cvs.. ora faccio il commit > > e quindi > > adoperarsi per farli funzionare sulle macchine attive. Quindi, > > aggiungere alle origini annunciate la playlist di Helix che gira su > > genni. >=20 > intende edificare una CDN separata dalla production? Come fatto gi=E0 > in precedenza? su smile, labtel, genni e pcuau? Che si basi in realt=E0 > solo su Helix...=20 no e si.=20 no, nel senso che appunto ho realizzato "meta.pm" proprio per avere entrambi (darwin ed helix) presenti su di una stessa macchina, quindi tutte le macchine per ora coinvolte (genni, labtel, citicord, cilea) dovrebbero avere entrambe le tecnologie di streaming attive. L'urgenza di cio', deriva dall'essermi reso conto che Darwin non funziona, quando su di una stessa macchina si impostano dei relay che hanno provenienze diverse. Ho segnalato la cosa sulla mailing list di apple, ma non ho avuto risposta. Quindi pregherei anche qualcuno di ripetere il test che ho svolto, hai visto mai avessi avuto le traveggole. Ma se le cose stanno cosi', si deve ripensare un po' all'architettura, ossia con Darwin, decadrebbe il concetto di "first hop", e i content provider dovrebbero tutti "sparare" l'RTP verso una Origin che faccia da "root" per tutte le distribuzioni. Quindi, in condizioni "tranquille" per la topologia, ogni nodo dovrebbe avere un unico "upstream" per tutti i program, ed il problema non si porrebbe. Il modello attuale dovrebbe invece mantenere validita' nel caso venga usato Helix. si (CDN separate) nel senso che prima o poi ne mettero' su una "stabile" con RRDM sulla macchina di cilea/garr, che esegue solo la versione dell'ultimo rilascio, con una password di autenticazione data solo a soggetti "sicuri", ed una seconda CDN, con RRDM su labtel come ora, in cui si tiene la versione di sviluppo, ed aperta al libero contributo di chi vuole (ma sinceramente mi aspettavo un po' piu' di feedback dal resto del pianeta). Quindi in definitiva, ci sarebbe da configurare Helix su queste macchine, in modo compatibile con Darwin. Si dovrebbe aggiungere il lancio di Helix in testa a launch.sh, e quindi operare il tutto come un unico utente "ocdn" (e' lo stesso su tutte le macchine, con stessa password eccetto che per cilea/garr). L'eseguibile di Helix (e cio' che gli serve) deve essere quindi posto nella directory di ocdn, a questo punto forse sotto production, e verificate le istruzioni di installazione ed eventualmente il file install. Consiglio che se e quando operiamo in ssh come utente ocdn, ci teniamo in contatto via messenger. Concludo dicendo che al Linuxclub pare cha abbiano scelto come macchina per fare da origin, l'unica macchina con la memoria rotta, e quindi per ora e' tutto impantanato. Invece, due giorni fa sono andato ad un incontro a uniroma3, ci sono quelli del DAMS (lettere) che vogliono fare una telestreet di ateneo, sono principalmente studenti laureandi e neo-laureati con profili redattoriali, li vedo ben intenzionati, ed hanno anche molto bene accolto la proposta di mandarli in streaming. Quando inizieranno le trasmissioni (fine maggio ???), visto che abito molto vicino a loro, se riesco a ricevere il loro segnale, li codifico da casa e li mando in streaming via adsl. Poi si vedra' :-) Infine, domani provo a fare l'upgrade di smile a fedora core 3, serve ad un altro tesista, ci mettiamo poi sopra un proxy SIP nell'ottica di dare un indirizzo SIP al personale della facolta' :-) alla prossima --=20 Alessandro Falaschi |
From: Marco V. <mar...@li...> - 2005-04-13 13:53:00
|
Salve! Il mar, 2005-04-12 alle 00:21, Alessandro Falaschi ha scritto: > Salve a tutti, >=20 > io purtroppo sono sempre piu' a corto di tempo, ma stasera mi sono mess= o > li' ad aggiornare le directory "production" delle macchine con l'ultima > versione del codice CVS, e sorprendentemente.. pare che funzioni tutto > :-) >=20 > A questo punto dovrebbe essere decaduta l'esigenza di allocare un > diverso IP per tecnologia di streaming, ed uno stesso nodo riesce a > registrare tutti i "transport" che si trova sotto, ed invocare l'uno o > l'altro in funzione del "transport" della program di cui realizzare il > relay. >=20 > La soluzione si basa su di un nuovo "strato di adattamento" chiamato > "Meta.pm", che a sua volta carica Darwin e Helix (che ora usano lo > stesso nome anche come packages). In alternativa a Meta, si puo' > caricare Dummy che annuncia tutti e tre i transport (ma non fa un tubo)= =2E >=20 > Ho realmente testato la cosa solo per Darwin e per Dummy, tra l'altro > con l'autenticazione RTSP disabilitata per le Origin. Ora chiederei a > Marco se puo' effettuare una serie di test per Helix, Ho svolto a casa un p=C3=B2 di test con Helix, e sembra che continui a funzionare correttamente. Tuttavia credo che si sia dimenticato di importare la variabile '$ad_layer' in 'Origin.pm' e di esportarla da 'OriginConfig', per consentire all'Origin di caricare lo strato di adattamento nel caso in cui lo streaming server sorgente sia coresidente. > e quindi > adoperarsi per farli funzionare sulle macchine attive. Quindi, > aggiungere alle origini annunciate la playlist di Helix che gira su > genni. intende edificare una CDN separata dalla production? Come fatto gi=C3=A0 in precedenza? su smile, labtel, genni e pcuau? Che si basi in realt=C3=A0 solo su Helix...=20 Marco |
From: Pierluigi V. <or...@us...> - 2005-04-13 11:49:45
|
On 04/13/2005 11:46 AM, Alessandro Falaschi wrote: > no no, non mi pare che sia questa la strada giusta... piuttosto pensavo, > ma non ho avuto il tempo di condurre ua analisi di nessun tipo, che > forse implementando un server TCP a livello di socket, che tenta di > emulare in modo molto rude il server http che reinvia l'immagine, > potremmo avere un qualche controllo in piu' su quel che succede sotto... Lo spero, anche se, a questo punto, sinceramente comincio ad essere un po' dubbioso al riguardo, sul fatto cioè che si riesca ad avere un qualche controllo in più sul socket senza ricorrere ad altri mezzi. In effetti, già adesso sto facendo in modo di far operare il server http direttamente sul socket (per esempio scavalcando i vari metodi di HTTP::Daemon e utilizzando send e close sul socket descriptor) ma i risultati continuano a non essere significativi. Ho appena fatto un test molto indicativo. Sto usando una cosa del tipo setsockopt($c, SOL_SOCKET, SO_LINGER, 10); ($s, $us) = gettimeofday; $sent_bytes = send($c, $image, 0); close $c; ($s1, $us1) = gettimeofday; per cercare di rilevare il tempo di invio dell'immagine. Ho espressamente settato SO_LINGER per dire al socket di non chiudersi in background nella speranza che close tornasse, appunto, dopo l'invio completo dei dati o addirittura dopo l'ACK finale del client. Manco per niente! :-( Mi è addirittura capitata una circostanza "fortunata" in cui, nell'invio del file, è stato necessario ritrasmettere il pacchetto, ma perl non se ne è minimamente accorto e ha preso comunque il tempo finale (ha cioè stoppato il cronometro) subito dopo l'invio dei dati, come se close fosse tornata immediatamente. > oppure le primitive a livello applicativo sono proprio cosi' > disaccoppiate dallo stack TCP, che bufferizza le operazioni per proprio > conto??? voglio dire, se un processo invia dei dati e quindi chiude il > socket, questo gli si chiude subito, prima che il kernel li invii > realmente, oppure la chiusura e' bloccata, finche' non e' riscontrata > dall'altro estremo??? ed anche se cosi' fosse (ossia se la chiusura a Dalle prove fatte sembra proprio che il socket venga chiuso (e close torni) subito senza attesa. Però che succede se il pacchetto si perde e anche le ritrasmissioni non vanno a buon fine? E' possibile che perl continui come se niente fosse? Ci sarà qualche altro meccanismo per evitare la perdita dei dati? Oppure c'è qualcosa che mi sfugge? > livello applicativo fosse istantanea), una idea potrebbe essere di > provare a riaprire il socket subito dopo, e capire cosi' se il socket > precedente si e' chiuso per davvero, e quindi poter prendere il tempo. > Che dice ? mi sono espresso in modo troppo confuso ?? No no, credo di aver capito :-) > oggi alle 15 ci sono, e penso anche venerdi, se viene me lo dica, > altrimenti vado via presto Oggi non posso, quindi verrei venerdì. >>Ha avuto qualche risposta riguardo alla tesi su PYTE? Forse lì potremmo trovare >>qualche spunto interessante... :-) > > > ho provato ora a scrivere a Franca Fiumana.... Ho visto che è già arrivata! Grazie. Saluti, Pierluigi |
From: Alessandro F. <aa...@li...> - 2005-04-13 09:49:41
|
Il mar, 2005-04-12 alle 16:09, Pierluigi Vittori ha scritto: > Io nel frattempo mi sono messo a sperimentare un po' la manipolazione a= basso=20 > livello dei pacchetti TCP tramite Net::Pcap e NetPacket::TCP e la cosa = sembra=20 > essere piuttosto interessante. >=20 > Oltre per=F2 a comportare l'eventuale richiesta di due ulteriori moduli= perl,=20 > questo approccio sembra portare al grosso inconveniente (ma non ho anco= ra avuto=20 > modo di accertarlo fino in fondo) di avere bisogno dei privilegi di roo= t per=20 > mettersi in ascolto sul device di rete, cosa che credo non sia proprio=20 > fattibilissima... no no, non mi pare che sia questa la strada giusta... piuttosto pensavo, ma non ho avuto il tempo di condurre ua analisi di nessun tipo, che forse implementando un server TCP a livello di socket, che tenta di emulare in modo molto rude il server http che reinvia l'immagine, potremmo avere un qualche controllo in piu' su quel che succede sotto... oppure le primitive a livello applicativo sono proprio cosi' disaccoppiate dallo stack TCP, che bufferizza le operazioni per proprio conto??? voglio dire, se un processo invia dei dati e quindi chiude il socket, questo gli si chiude subito, prima che il kernel li invii realmente, oppure la chiusura e' bloccata, finche' non e' riscontrata dall'altro estremo??? ed anche se cosi' fosse (ossia se la chiusura a livello applicativo fosse istantanea), una idea potrebbe essere di provare a riaprire il socket subito dopo, e capire cosi' se il socket precedente si e' chiuso per davvero, e quindi poter prendere il tempo. Che dice ? mi sono espresso in modo troppo confuso ?? oggi alle 15 ci sono, e penso anche venerdi, se viene me lo dica, altrimenti vado via presto > Ha avuto qualche risposta riguardo alla tesi su PYTE? Forse l=EC potrem= mo trovare=20 > qualche spunto interessante... :-) ho provato ora a scrivere a Franca Fiumana.... --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Pierluigi V. <or...@us...> - 2005-04-12 14:09:49
|
On 04/06/2005 01:52 PM, Alessandro Falaschi wrote: > e se chiedessimo due immagini? per scaricare la seconda, il client deve > aver gia' scaricato del tutto la prima, con tutti gli ack al posto > giusto... o no ? > > ... questo ripropone la domanda, ma un client/browser web, siamo sicuri > che serializzi le richieste, oppure puo' aprire piu' connessioni in > parallelo (quando accede agli oggetti referenziati da una stessa pagina) > ? Non so, potrei provare a sniffare qualche richiesta con Firefox e Konqueror, ma questo però non ci garantirebbe che tutti i browser si comportano allo stesso modo. Io nel frattempo mi sono messo a sperimentare un po' la manipolazione a basso livello dei pacchetti TCP tramite Net::Pcap e NetPacket::TCP e la cosa sembra essere piuttosto interessante. Oltre però a comportare l'eventuale richiesta di due ulteriori moduli perl, questo approccio sembra portare al grosso inconveniente (ma non ho ancora avuto modo di accertarlo fino in fondo) di avere bisogno dei privilegi di root per mettersi in ascolto sul device di rete, cosa che credo non sia proprio fattibilissima... Ha avuto qualche risposta riguardo alla tesi su PYTE? Forse lì potremmo trovare qualche spunto interessante... :-) Saluti, Pierluigi |
From: Alessandro F. <aa...@li...> - 2005-04-11 22:20:31
|
Salve a tutti, io purtroppo sono sempre piu' a corto di tempo, ma stasera mi sono messo li' ad aggiornare le directory "production" delle macchine con l'ultima versione del codice CVS, e sorprendentemente.. pare che funzioni tutto :-) A questo punto dovrebbe essere decaduta l'esigenza di allocare un diverso IP per tecnologia di streaming, ed uno stesso nodo riesce a registrare tutti i "transport" che si trova sotto, ed invocare l'uno o l'altro in funzione del "transport" della program di cui realizzare il relay. La soluzione si basa su di un nuovo "strato di adattamento" chiamato "Meta.pm", che a sua volta carica Darwin e Helix (che ora usano lo stesso nome anche come packages). In alternativa a Meta, si puo' caricare Dummy che annuncia tutti e tre i transport (ma non fa un tubo). Ho realmente testato la cosa solo per Darwin e per Dummy, tra l'altro con l'autenticazione RTSP disabilitata per le Origin. Ora chiederei a Marco se puo' effettuare una serie di test per Helix, e quindi adoperarsi per farli funzionare sulle macchine attive. Quindi, aggiungere alle origini annunciate la playlist di Helix che gira su genni. Ma la vera ciliegina, sarebbe di realizzare un cgi equivalente a quello che lancia la live tv su darwin, usando la seconda scheda video di cui e' equipaggiato genni, ed annunciare una live tv helix, per esempio con banda idonea al modem analogico. che dite, ci si puo' pensare ?? a presto ! -- Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Alessandro F. <aa...@li...> - 2005-04-06 11:51:50
|
Il mer, 2005-04-06 alle 13:18, Pierluigi Vittori ha scritto: > Potremmo intanto ricorrere alla tecnologia e pensare ad una videoconf... per oggi sono in fuga, no es possible, forse domani pom ? > Il problema a questo punto sembra essere trovare una funzione perl di invio > dati sul socket che ritorni alla ricezione di un qualche ACK, che aspetti una > conferma dell'avvenuta corretta trasmissione. > Vado a cercare un po' in giro... :-) e se chiedessimo due immagini? per scaricare la seconda, il client deve aver gia' scaricato del tutto la prima, con tutti gli ack al posto giusto... o no ? ... questo ripropone la domanda, ma un client/browser web, siamo sicuri che serializzi le richieste, oppure puo' aprire piu' connessioni in parallelo (quando accede agli oggetti referenziati da una stessa pagina) ? ... stasera ci ripenso un po'..... -- Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Pierluigi V. <p.v...@ra...> - 2005-04-06 11:19:08
|
On 06/04/2005 01:23, Alessandro Falaschi wrote: > e se prendiamo il tempo anche quando ritorna da send_file_response, con > una immagine molto piccola ? Non c'è praticamente differenza perché sia il "200 OK" che il pacchetto contenente il file vengono sparati via in sequenza da perl. Visto che, come avevamo già rilevato, l'invio vero e proprio dei bytes dell'immagine avviene tutto insieme e la funzione ritorna immediatamente, il tempo di ritorno da send_file_response praticamente coincide (a meno di qualche ms) con il tempo di ritorno da get_request. :-( > dunque, credo che il client invii il GET _immediatamente_ appresso > all'ACK di apertura TCP (potrebbe verificarlo sniffando sul lato > client), Sì, confermo. > invece, se spostiamo lo stop del cronometro dopo il send_file_response, > inviando una immagine che entra tutta dentro un pacchetto, e > confrontiamo il valore dell'arresto con i tempi dei pacchetti sniffati, > cosa otteniamo ??? Perche', se ci stesse dentro > > ethereal | perl | > | | accept (blocking) > | SYN > | > | SYN+ACK < | > | ACK > | > | | ritorna da accept > | | (clock start) > | HTTP GET > | > | ACK < | > | | ritorna da get_request > | HTTP 200 OK < | > | (con payload) | > | TCP ACK > | > | | ritorna da send_file_response > | | (clock stop) > > allora avremmo tirato dentro un RTT :-) puo' fare anche questa analisi ? Purtroppo il ritorno da send_file_response avviene immediatamente, senza aspettare l'ACK corrispondente, quindi non sembra essere significativo ai fini della determinazione dell'RTT. > ... e mi viene da pensare: se le immagini sono ad esempio 2, come si > modifica la traccia ? potremmo anche fare cosi' per aumentare il numero > di RTT considerati! sempre che, sniffando, non trovi che il perl usa > comunque piu' pacchetti per inviare il 200 OK, e non si accorga che per > ognuno di questi c'e' il relativo TCP ACK, perche' se cosi' fosse, > avremmo gia' raccolto un po' di RTT... No, il 200 OK viene inviato in un unico pacchetto e, come detto, immediatamente dopo, senza cioè accorgersi dei relativi ACK, viene mandato il contenuto del file. > ... pero' faccio un po' fatica a questo punto a gestire tutto "a voce > per scritto"... anche i "vecchi tempi" in cui tesista e relatore > sedevano assieme davanti al computer su cui si svolgono i test, non > erano da buttare via del tutto... Sono d'accordissimo, anche io mi comincio un po' a impicciare con queste spiegazioni scritte. Visti però gli ultimi eventi e la situazione che si sta creando per le strade (ieri ho avuto veramente paura di restare incastrato in mezzo al traffico...), eviterei di vederci questa settimana in facoltà, che ne dice? Potremmo intanto ricorrere alla tecnologia e pensare ad una videoconf... >>Sì, credo proprio che, per avere un controllo un po' più diretto su cosa >>succede all'invio/ricezione pacchetti, sia necessario operare ad un livello più >>basso. > > > concediamoci ancora una chance :-) Ok! Continuo a sniffare in cerca di tempi interessanti e significativi... :-) Il problema a questo punto sembra essere trovare una funzione perl di invio dati sul socket che ritorni alla ricezione di un qualche ACK, che aspetti una conferma dell'avvenuta corretta trasmissione. Vado a cercare un po' in giro... :-) Saluti, Pierluigi |
From: Alessandro F. <aa...@li...> - 2005-04-05 23:22:26
|
Il mar, 2005-04-05 alle 16:21, Pierluigi Vittori ha scritto: > Dunque, ho verificato il seguente funzionamento, spostando il clock sta= rt > appena c'=E8 l'uscita da accept e clock stop appena ritorna da get_requ= est: >=20 > ethereal | perl | > | | accept (blocking) > | SYN > | > | SYN+ACK < | > | ACK > | > | | ritorna da accept > | | (clock start) > | GET > | > | ACK < | > | | ritorna da get_request > | | (clock stop) > | 200 OK < | e se prendiamo il tempo anche quando ritorna da send_file_response, con una immagine molto piccola ? > S=EC, sono confrontabili se ethereal e il server perl girano sulla stes= sa=20 > macchina=20 chiaro :-) si, pensavo che cosi' fosse! portatile piero <----> adsl piero <----> labtel client server client sniffed > [...] il tempo tra accept e get_request [...] =E8 il tempo che intercor= re=20 > tra la ricezione dell'ACK finale (da parte del server) della sequenza S= YN,=20 > SYN+ACK, ACK e l'_invio_ dell'ACK (sempre da parte del server) in rispo= sta al=20 > GET del client. >=20 > Il tutto sembrerebbe poco correlato all'RTT, e in effetti i tempi tipic= i di=20 > questo cronometraggio per le richieste tra labtel e la mia macchina si = aggirano=20 > intorno ai 10 ms, mentre ping riporta un RTT medio di 75 ms. dunque, credo che il client invii il GET _immediatamente_ appresso all'ACK di apertura TCP (potrebbe verificarlo sniffando sul lato client), quindi intanto che il GET e' gia' in viaggio, la accept si sblocca (poniamo che abbia 30-50 ms di latenza a sbloccarsi ???). Quindi, (in accordo alla sua misura) get_request riceve l'HTTP GET, invia il TCP ACK, e torna. Percio' alla fine, misuriamo solo l'ultima parte del viaggo della GET, e la latenza di perl ad inviare l'ACK. invece, se spostiamo lo stop del cronometro dopo il send_file_response, inviando una immagine che entra tutta dentro un pacchetto, e confrontiamo il valore dell'arresto con i tempi dei pacchetti sniffati, cosa otteniamo ??? Perche', se ci stesse dentro ethereal | perl | | | accept (blocking) | SYN > | | SYN+ACK < | | ACK > | | | ritorna da accept | | (clock start) | HTTP GET > | | ACK < | | | ritorna da get_request | HTTP 200 OK < | | (con payload) | | TCP ACK > | | | ritorna da send_file_response | | (clock stop) allora avremmo tirato dentro un RTT :-) puo' fare anche questa analisi ? ... e mi viene da pensare: se le immagini sono ad esempio 2, come si modifica la traccia ? potremmo anche fare cosi' per aumentare il numero di RTT considerati! sempre che, sniffando, non trovi che il perl usa comunque piu' pacchetti per inviare il 200 OK, e non si accorga che per ognuno di questi c'e' il relativo TCP ACK, perche' se cosi' fosse, avremmo gia' raccolto un po' di RTT... ... pero' faccio un po' fatica a questo punto a gestire tutto "a voce per scritto"... anche i "vecchi tempi" in cui tesista e relatore sedevano assieme davanti al computer su cui si svolgono i test, non erano da buttare via del tutto... > A proposito, una domanda: perch=E9 non abbiamo preso in considerazione = l'ipotesi=20 > di utilizzare ping per rilevare l'RTT tra il LH e il viewer? > Perch=E9 ping potrebbe essere filtrato da qualche firewall lungo la str= ada? > Oppure ci sono altri inconvenienti per il suo utilizzo in questo caso? beh il viewer non e' una entita' OpenCDN, quindi il ping dovrebbe farlo il server, una volta noto l'IP del client, per acquisire il quale, deve comunque essere ricevuta la richiesta HTTP. E' una ipotesi anche questa, anche se mi pare piu' complicata, in quanto il ping dovrebbe comunque farlo un processo forkato rispetto a quello del server HTTP, quindi ritiriamo in ballo i tempi di fork... oppure e' lo stesso processo che fa il ping prima di eseguire la get_request, oppure prima del send_file_response... oddio tutto e' posibile, ma dato che tanto la richiesta HTTP va fatta, se ce la caviamo solo con quella, potrebbe essere meglio non complicarsi la vita... senza contare che si, hai visto mai qualcuno filtrasse l'ICMP ??? > S=EC, credo proprio che, per avere un controllo un po' pi=F9 diretto su= cosa=20 > succede all'invio/ricezione pacchetti, sia necessario operare ad un liv= ello pi=F9=20 > basso. concediamoci ancora una chance :-) > > Ho scritto a Marcello Barbieri, se mi rimanda la tesi su PYTE del > > Cineca. >=20 > Bene! Ha gi=E0 avuto qualche risposta? nulla... chissa' se riceve ancora la sua email al cineca ? altrimenti devo provare con Franca Fiumana.... --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Pierluigi V. <p.v...@ra...> - 2005-04-05 14:22:06
|
On 02/04/2005 18:26, Alessandro Falaschi wrote: > nelle mie intenzioni, pensavo interessante rilevare anche il tempo tra > la accept (da cui si dovrebbe uscire alla ricezione del SYN (o piu' in > la??)) e la get_request (da cui si dovrebbe uscire dopo SYN-ACK, ACK, > GET, ACK). questo primo intervallo dovrebbe essere solo sensibile > all'RTT e non alla dimensione dell'immagine, e quindi indicativo della > "vicinanza". Dunque, ho verificato il seguente funzionamento, spostando il clock start appena c'è l'uscita da accept e clock stop appena ritorna da get_request: ethereal | perl | | | accept (blocking) | SYN > | | SYN+ACK < | | ACK > | | | ritorna da accept | | (clock start) | GET > | | ACK < | | | ritorna da get_request | | (clock stop) | 200 OK < | ecc. > sempre nelle mie intenzioni, avrei voluto porre le misurazioni possibili > da parte del perl, a stretto confronto con quelle rilevate con ethereal. > In quest'ultimo, (almeno nella versione che ho) e' possibile da > "preferences" impostare la visualizzazione della colonna "time" come > "tempo assoluto" (in realta' non mi fa effetto subito, ma devo > uscire-rientrare). In questo modo, le misure di Perl ed ethereal > dovrebbero essere confrontabili, e dovrebbe essere possibile tracciare > un diagramma del tipo Sì, sono confrontabili se ethereal e il server perl girano sulla stessa macchina (e infatti così facendo sono riuscito a vedere il comportamento riportato sopra), ma non ho trovato il modo di sincronizzare i due stream TCP provenienti da due sniffate su due macchine diverse. > intenzione di fare, sembra impossibile. Inoltre, c'e' da vedere se > qualcosa cambia (per macchine vicine e lontane) includendo anche il > tempo tra accept e get_request. In effetti, alla luce dello schema sopra riportato, il tempo tra accept e get_request non sembrerebbe molto indicativo perché è il tempo che intercorre tra la ricezione dell'ACK finale (da parte del server) della sequenza SYN, SYN+ACK, ACK e l'_invio_ dell'ACK (sempre da parte del server) in risposta al GET del client. Il tutto sembrerebbe poco correlato all'RTT, e in effetti i tempi tipici di questo cronometraggio per le richieste tra labtel e la mia macchina si aggirano intorno ai 10 ms, mentre ping riporta un RTT medio di 75 ms. A proposito, una domanda: perché non abbiamo preso in considerazione l'ipotesi di utilizzare ping per rilevare l'RTT tra il LH e il viewer? Perché ping potrebbe essere filtrato da qualche firewall lungo la strada? Oppure ci sono altri inconvenienti per il suo utilizzo in questo caso? > Se il tempo resta sempre costante, forse > dovremmo provare con qualcosa di piu' basso livello rispetto ad > HTTP:Daemon, in cui potremmo veramente arrivare al dettaglio degli > eventi atomici del TCP. D'altra parte, non vogliamo un vero server web, > ma solo un socket TCP che quando riceve GET, spedisce una immagine (con > qualche header HTTP in testa) Sì, credo proprio che, per avere un controllo un po' più diretto su cosa succede all'invio/ricezione pacchetti, sia necessario operare ad un livello più basso. >>Invece, il tempo effettivo tra SYN e GET sembra essere costante e seguire molto >>bene, come era da aspettarsi, l'RTT rilevato con il ping. > > > e questo e' bene :-) solo che dovrebbe essere misurabile dal Perl Esatto, e questo sembra confermare che probabilmente dobbiamo operare a più basso livello. > Ho scritto a Marcello Barbieri, se mi rimanda la tesi su PYTE del > Cineca. Bene! Ha già avuto qualche risposta? Saluti, Pierluigi |
From: Alessandro F. <aa...@li...> - 2005-04-02 16:25:52
|
Il ven, 2005-04-01 alle 14:44, Pierluigi Vittori ha scritto: > Ho fatto un po' di prove e ho preso un po' di tempi relativi all'invio = delle=20 > immagini da usare nel probe LH -> viewer. > Il server http usato =C3=A8 l'HTTP::Daemon, che girava su labtel, mentr= e le=20 > richieste partivano dal mio computer collegato su ADSL. eccomi, un vero rimpiscatole, come al solito... :-) due osservazioni (per ora): - ha fatto rilevamenti analoghi per un collegamento piu' breve, ad esempio interno a casa ? - ha fatto prove ripetute, e mediato i risultati ? (con varianza, eventualmente) > ho preso il tempo "Perl" in questo modo: > - fai partire il cronometro; > - manda i byte dell'immagine (tutti insieme, in un'unica istruzione) su= l socket=20 > verso il client; > - ferma il cronometro, > cosicch=C3=A9 i meccanismi interni della gestione dell'invio da parte d= el perl=20 > rimangono nascosti. quindi una cosa del tipo my $d =3D HTTP::Daemon->new =E2=94=82=E2=94=82 die; print "Please contact me at: <URL:", $d->url, ">\n"; while (my $c =3D $d->accept) { while (my $r =3D $c->get_request) { if ($r->method eq =E2=80=99GET=E2=80=99 and $r->url->pat= h eq "/xyzzy") { -- parte cronometro $c->send_file_response("/etc/passwd"); -- ferma cronometro=20 } else { $c->send_error(RC_FORBIDDEN) } } $c->close; undef($c); } ??? nelle mie intenzioni, pensavo interessante rilevare anche il tempo tra la accept (da cui si dovrebbe uscire alla ricezione del SYN (o piu' in la??)) e la get_request (da cui si dovrebbe uscire dopo SYN-ACK, ACK, GET, ACK). questo primo intervallo dovrebbe essere solo sensibile all'RTT e non alla dimensione dell'immagine, e quindi indicativo della "vicinanza". > Nel frattempo mi ero messo a sniffare il traffico client <-> server e, = dai=20 > risultati, ho estrapolato due tempi principali: > - il tempo tra il SYN del client e il GET del client stesso > - il tempo tra il GET del client e la fine dell'invio dell'immagine da = parte=20 > del server. sempre nelle mie intenzioni, avrei voluto porre le misurazioni possibili da parte del perl, a stretto confronto con quelle rilevate con ethereal. In quest'ultimo, (almeno nella versione che ho) e' possibile da "preferences" impostare la visualizzazione della colonna "time" come "tempo assoluto" (in realta' non mi fa effetto subito, ma devo uscire-rientrare). In questo modo, le misure di Perl ed ethereal dovrebbero essere confrontabili, e dovrebbe essere possibile tracciare un diagramma del tipo ethereal | Perl | | | t0 | SYN > | | t1 | accept t2 | SYN+ACK < | t3 | ACK > | t4 | GET > | t5 | ACK < | | t6 | get_request t7 | 200 OK < | t8 | data < | ... etc... in modo da aver chiaro cosa stiamo guardando. L'ideale sarebbe creare il "grafico" in modo automatico :-), eventualmente "fondendo" i risultati dei due sniffaggi, ordinati per tempo assoluto... ma puo' essere piu' che sufficiente un grafico riassuntivo finale fatto a mano a posteriori, dopo l'analisi di diverse tracce. > Sembra proprio che, per l'invio di immagini piccole (fino a 10 kB), la=20 > differenza tra tempo perl e tempo effettivo sia enorme: in particolare = il tempo=20 > perl rimane pressoch=C3=A9 costante mentre quello effettivo cresce al c= rescere della=20 > dimensione dell'immagine. preoccupante :-( c'e' da verificare se il tempo perl resta lo stesso anche per una "macchina vicina", nel qual caso la misura che abbiamo intenzione di fare, sembra impossibile. Inoltre, c'e' da vedere se qualcosa cambia (per macchine vicine e lontane) includendo anche il tempo tra accept e get_request. Se il tempo resta sempre costante, forse dovremmo provare con qualcosa di piu' basso livello rispetto ad HTTP:Daemon, in cui potremmo veramente arrivare al dettaglio degli eventi atomici del TCP. D'altra parte, non vogliamo un vero server web, ma solo un socket TCP che quando riceve GET, spedisce una immagine (con qualche header HTTP in testa) > Poi, dai 10 kB in poi, i due tempi sembrano cominciare ad assumere un a= ndamento=20 > simile, seppure con valori discordanti ma indicativi (valori un po' men= o=20 > discordanti se si sottrae dal tempo effettivo un RTT dovuto a GET/ACK, = non=20 > presente nel tempo perl). di nuovo, occorre correlare i risultati all'RTT vero tra le macchine, e confrontare i risultati per macchine a diversa distanza. > Invece, il tempo effettivo tra SYN e GET sembra essere costante e segui= re molto=20 > bene, come era da aspettarsi, l'RTT rilevato con il ping. e questo e' bene :-) solo che dovrebbe essere misurabile dal Perl > Ho anche normalizzato i tempi effettivi con la dimensione delle immagin= i in=20 > modo da ottenere un valore indicativo per la velocit=C3=A0 di trasmissi= one: il=20 > risultato sembra confermare molto bene lo "slow start" del protocollo T= CP, la=20 > cui influenza, ovviamente, risulta molto pi=C3=B9 visibile con le immag= ini di=20 > piccole dimensioni. la "saturazione" della velocita' percepita sarebbe piu' evidente se le ascisse fossero "in scala" (ma notatolo, e' evidente! :-)). Come dicevo, a causa dello slowstart, una stima esatta "della banda" puo' ottenersi solo con immagini relativamente grandi, ma potrebbe comunque andare, per fare un -confronto- tra coppie di macchine diverse. Anche se, come ho gia' detto, la banda percepita alla fine risulta la stessa tra uno stesso utente periferico, e macchine diverse poste su BackBone, in quanto dipende solo da quella dell'ultimo miglio dell'utente periferico. Invece, privilegerei misure strettamente legate all'RRT, ossia alla distanza. Ho scritto a Marcello Barbieri, se mi rimanda la tesi su PYTE del Cineca. Buona domenica --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
From: Pierluigi V. <or...@us...> - 2005-04-02 10:09:35
|
Il messaggio l'ho spedito quasi 24 ore fa, ma io non l'ho ancora ricevuto. Provo a rimandarlo. -------- Original Message -------- Subject: Tempi invio immagini probe Date: Fri, 01 Apr 2005 14:44:35 +0200 From: Pierluigi Vittori <or...@us...> To: ope...@li... Ho fatto un po' di prove e ho preso un po' di tempi relativi all'invio delle immagini da usare nel probe LH -> viewer. Il server http usato è l'HTTP::Daemon, che girava su labtel, mentre le richieste partivano dal mio computer collegato su ADSL. Ne è venuto fuori il grafico che trovate allegato. Ho usato varie immagini di diverse dimensioni per vedere le diverse reazioni, e ho preso il tempo "Perl" in questo modo: - fai partire il cronometro; - manda i byte dell'immagine (tutti insieme, in un'unica istruzione) sul socket verso il client; - ferma il cronometro, cosicché i meccanismi interni della gestione dell'invio da parte del perl rimangono nascosti. Nel frattempo mi ero messo a sniffare il traffico client <-> server e, dai risultati, ho estrapolato due tempi principali: - il tempo tra il SYN del client e il GET del client stesso - il tempo tra il GET del client e la fine dell'invio dell'immagine da parte del server. Sembra proprio che, per l'invio di immagini piccole (fino a 10 kB), la differenza tra tempo perl e tempo effettivo sia enorme: in particolare il tempo perl rimane pressoché costante mentre quello effettivo cresce al crescere della dimensione dell'immagine. Poi, dai 10 kB in poi, i due tempi sembrano cominciare ad assumere un andamento simile, seppure con valori discordanti ma indicativi (valori un po' meno discordanti se si sottrae dal tempo effettivo un RTT dovuto a GET/ACK, non presente nel tempo perl). Invece, il tempo effettivo tra SYN e GET sembra essere costante e seguire molto bene, come era da aspettarsi, l'RTT rilevato con il ping. Ho anche normalizzato i tempi effettivi con la dimensione delle immagini in modo da ottenere un valore indicativo per la velocità di trasmissione: il risultato sembra confermare molto bene lo "slow start" del protocollo TCP, la cui influenza, ovviamente, risulta molto più visibile con le immagini di piccole dimensioni. Saluti, Pierluigi |
From: Pierluigi V. <or...@us...> - 2005-04-01 12:44:52
|
Ho fatto un po' di prove e ho preso un po' di tempi relativi all'invio delle immagini da usare nel probe LH -> viewer. Il server http usato è l'HTTP::Daemon, che girava su labtel, mentre le richieste partivano dal mio computer collegato su ADSL. Ne è venuto fuori il grafico che trovate allegato. Ho usato varie immagini di diverse dimensioni per vedere le diverse reazioni, e ho preso il tempo "Perl" in questo modo: - fai partire il cronometro; - manda i byte dell'immagine (tutti insieme, in un'unica istruzione) sul socket verso il client; - ferma il cronometro, cosicché i meccanismi interni della gestione dell'invio da parte del perl rimangono nascosti. Nel frattempo mi ero messo a sniffare il traffico client <-> server e, dai risultati, ho estrapolato due tempi principali: - il tempo tra il SYN del client e il GET del client stesso - il tempo tra il GET del client e la fine dell'invio dell'immagine da parte del server. Sembra proprio che, per l'invio di immagini piccole (fino a 10 kB), la differenza tra tempo perl e tempo effettivo sia enorme: in particolare il tempo perl rimane pressoché costante mentre quello effettivo cresce al crescere della dimensione dell'immagine. Poi, dai 10 kB in poi, i due tempi sembrano cominciare ad assumere un andamento simile, seppure con valori discordanti ma indicativi (valori un po' meno discordanti se si sottrae dal tempo effettivo un RTT dovuto a GET/ACK, non presente nel tempo perl). Invece, il tempo effettivo tra SYN e GET sembra essere costante e seguire molto bene, come era da aspettarsi, l'RTT rilevato con il ping. Ho anche normalizzato i tempi effettivi con la dimensione delle immagini in modo da ottenere un valore indicativo per la velocità di trasmissione: il risultato sembra confermare molto bene lo "slow start" del protocollo TCP, la cui influenza, ovviamente, risulta molto più visibile con le immagini di piccole dimensioni. Saluti, Pierluigi |