opencdn-devel-it Mailing List for OpenCDN
Brought to you by:
aalef
Menu
▾
▴
opencdn-devel-it — Development coordination (in Italian)
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. <al...@in...> - 2008-05-06 09:25:08
|
Ieri notte, col favore delle ore piccole, la versione di sviluppo dell'Origin e CPK ha raggiunto una maturità sufficiente a.. permettermi stamattina di constatarne il funzionamento :-) Evviva Francesco!! Per oggi, lascerò attivo uno stream che parte da casa mia, dietro NAT, descritto dal TAG "AlefDarwin", e che usa Darwin come relay su labtel. Di seguito, alcuni commenti ed impressioni d'uso. 1) ho inizialmente provato a definire un contenuto che usasse VLC come trasporto, e dunque VLC anche come relay, ma non ha funzionato. In quel caso il problema è che, essendo io nattato anche come client richiedente finale, non posso ricevere l'RTP su UDP negoziato su porte qualunque durante il SETUP RTSP. Il mio VLC client, dopo 10 secondi di timeout, passa a richiedere uno stream interleaved con RTP su TCP, ma la richiesta fallisce perchè il VLC che fa da relay non è in grado di soddisfare una richiesta del genere. 2) il contenuto con tag "AlefDarwin" dichiara invece un trasporto "Darwin", che supporta l'erogazione di RTP su TCP dal lato server. Quindi, quando VLC lo richiede, la richiesta può essere soddisfatta, tranne che.... a me capita che il VLC client, emette praticamente subito un RTSP TEARDOWN. A quanto pare, anche se afferma di aver aspettato 10 secondi che arrivasse l'RTP su TCP, VLC si spazientisce subito. A prima vista, sembra un baco di VLC, che confonde il timer della prima attesa (quella per l'RTP su UDP) con quello per la seconda. Qualcuno che legge, può confermare/smentire questa analisi? 3) richiedendo lo stesso tag "AlefDarwin" con Totem, invece... la cosa funziona!!! sniffando, osservo che * il primo SETUP della richiesta RTSP di Totem contiene ben tre alternative tutte assieme: RTP/UDP, RTP su multicast, RTP/TCP interleaved * dopo 5 secondi di attesa infruttuosa, lo stream viene messo prima in pausa, e poi eseguito l'RTSP teardown * segue immediatamente un nuovo SETUP, che richiede stavolta solo RTP/TCP interleaved * trascorsi circa 700 msec dal PLAY, iniziano ad arrivare i pacchetti dell'RTP su RTSP, ed io vedo lo stream 4) a questo punto, mi sono ricordato che un nodo basato su VLC, dovrebbe offrire anche uno streaming su HTTP, mediante il quale l'RTP è incapsulato sul socket TCP usato dal'HTTP, e con questo risolvere il problema 1). Forse non ho fatto caso al link "HTTP" nella pagine del risultato?? Riprovo ad invocare il TAG "Alef" del punto 1), ma... ora fallisce miseramente :-( Sniffando, osservo che la richiesta RTSP proveniente dal nodo-relay-VLC e diretta verso la mia origin VLC viene rifiutata con un RST/TCP. Con Netstat, mi accorgo che il mio CPK-VLC non ascolta più nulla sulla porta 554. Provando ad invocare (ad es da browser) il pre-requisito associato al tag "Alef", la richiesta non produce risposta. X FRANCESCO: ... ieri abbiamo discusso della tesi, di come è ora, e di come mettere in evidenza le parti più legate allo specifico del lavoro svolto... ora non so dire se fosse per l'ora tarda, ma non ricordo se c'era il dettaglio di cosa accade, in corrispondenza dell'invocazione del prerequisito. Probabilmente una formalizzazione in forma tabellare o di elenco, di quali sono le possibili interazioni tra lo strato di adattamento, ed il VLC che sta lì sotto, sarebbe di aiuto, così come (oppure) un diagramma temporale che mostri le chiamate non tanto tra entità, quanto tra strati, e VLC. Ora mi dedico alla lezione di domani..... buon martedì Ale -- Alessandro Falaschi Professore Aggregato e Ricercatore Home page: http://infocom.uniroma1.it/alef/wiki/pmwiki.php Tel VoIP: sip:al...@in... sip:aal...@pr... sip:174...@pr... skype:alef.ala Messenger: msn:aa...@li... aalef_59 su Yahoo alef.ala su Gtalk/Jabber |
|
From: alef <aa...@li...> - 2008-05-04 00:02:23
|
... mi rispondo da solo.... poco dopo aver scritto la mia invocazione di aiuto, leggendo http://search.cpan.org/~jesse/HTTP-Server-Simple-0.33/lib/HTTP/Server/Simple.pm http://perldoc.perl.org/base.html ho realizzato che VLCadm.pm in effetti è una sottoclasse di HTTP::Server::Simple::CGI, e quindi il new sta li. Però, il motivo per cui l'Origin non riparte, ancora non si spiega. Investigando VLCadm, osservo che la ri-partenza dell'Origin dovrebbe essere causata da restart_origin, che a quanto capisco, opera inviando un segnale kill 15 al "processo padre". Però a quanto pare, l'effetto di questo segnale, non è di far ripartire l'Origine, ma di ucciderla senza scampo. Continuando l'indagine, noto che la subroutine "update_contents_ip" che compariva in VLCadm, compare ora anche nell'Origin. Se questo passaggio è spiegato nella tesi, ben venga; altrimenti, è possibile avere una descrizione del perché di questo spostamento? Mi pare di ricordare, all'inizio del lavoro, dei discorsi sul fatto che facendo ripartire l'Origin, si perdevano gli streaming in corso, forse il motivo è questo, però allora, che ci sta a fare il codice di "update_contents_ip" ancora presente in VLCadm.pm ? Tornando alla osservazione che ha suscitato questa discussione, ora il problema è quello di far ripartire l'Origin, dopo avere immesso via web, la $oCDNpassword che compare in CommConf, e necessaria alla registrazione presso l'RRDM. Per come è ora, questa operazione non viene svolta da "update_contents_ip", il quale infatti non opera su CommConf. Inoltre, l'obiezione che "vengono abbattuti i programmi in corso", in questo caso non sussiste, in quanto senza la corretta $oCDNpassword, nessun programma avrebbe senso. Come se può risolvere? Cosa è cambiato rispetto al metodo precedente, che invece funzionava? ... investigando con i potenti mezzi del cvs, vedo che il VLCadm.pm versione 1.16, creava uno script, che veniva invocato prima che VLCadm::restart_origin terminasse, e che provvedeva a ri-lanciare l'Origin. Ora, queste istruzioni sono commentate. Possono essere ri-esumate senza troppi problemi?? Francesco si chiederà: ma tutti questi problemi, per scrivere CommConf::oCDNpassword? non si potrebbe scrivere a mano? La risposta è: no, l'interfaccia web ci sta apposta, perché non si debbano andare a toccare i files di configurazione per ora, mi basto così :-) Ale Il giorno sab, 03/05/2008 alle 18.14 +0200, alef ha scritto: > Lo scrivo qui, anche se principalmente per Francesco... > > Oggi ho provato a ripercorrere i passi esposti nel readme del CPK, e... > mi son bloccato sull'edit da web della password per la registrazione > all'RRDM. In due parole, l'Origin non riparte. > > Ma la cosa per me più tragica, è che mi son "perso" nel tentare di > capire quel che succede, infatti quando alla riga 802 di Origin.pm viene > invocato > > my $server = VLCadm->new(); > > non capisco cosa viene eseguito. Ho anche provato a rileggere la parte > relativa della tesi di Cintio, ma... senza successo :-( Il mio problema, > è che in VLCadm.pm, non trovo nessuna subroutine "new"... sarà la mia > scarsa conoscenza di perl, a trarmi in inganno?? Francesco, puoi cercare > di capire che succede, e documentare le cose da qualche parte? anche, > per dire, nei commenti interni al codice?? > > ... penso che l'inizializzazione dello strato di adattamento, dovrebbe > essere unificata tra Origin e Nodi.... > > In tutti i modi, ecco i commenti al mio ultimo commit sul CVS: > > * Re-cecking of README.CPK for latest additions > * some minor adjustments at the adaptation layer messages for Darwin and > Helix > * The web interface for CPK managment now starts only if $is_cpk is set > to true > * When oCDN password is unset or wrong, the CPK web interface should > allow to manually set it, and restart the origin. Instead, Origin > re-start fails. Why? > > .... ci possiamo organizzare per lunedì, anche una video conferenza > potrebbe forse aiutare? > > saluti, per ora > Ale -- Alessandro Falaschi http://infocom.uniroma1.it/alef/wiki/pmwiki.php sip:al...@in... sip:aal...@pr... sip:174...@pr... skype:alef.ala msn:aa...@li... aalef_59 su Yahoo alef.ala su Gtalk/Jabber |
|
From: alef <aa...@li...> - 2008-05-03 16:14:48
|
Lo scrivo qui, anche se principalmente per Francesco... Oggi ho provato a ripercorrere i passi esposti nel readme del CPK, e... mi son bloccato sull'edit da web della password per la registrazione all'RRDM. In due parole, l'Origin non riparte. Ma la cosa per me più tragica, è che mi son "perso" nel tentare di capire quel che succede, infatti quando alla riga 802 di Origin.pm viene invocato my $server = VLCadm->new(); non capisco cosa viene eseguito. Ho anche provato a rileggere la parte relativa della tesi di Cintio, ma... senza successo :-( Il mio problema, è che in VLCadm.pm, non trovo nessuna subroutine "new"... sarà la mia scarsa conoscenza di perl, a trarmi in inganno?? Francesco, puoi cercare di capire che succede, e documentare le cose da qualche parte? anche, per dire, nei commenti interni al codice?? ... penso che l'inizializzazione dello strato di adattamento, dovrebbe essere unificata tra Origin e Nodi.... In tutti i modi, ecco i commenti al mio ultimo commit sul CVS: * Re-cecking of README.CPK for latest additions * some minor adjustments at the adaptation layer messages for Darwin and Helix * The web interface for CPK managment now starts only if $is_cpk is set to true * When oCDN password is unset or wrong, the CPK web interface should allow to manually set it, and restart the origin. Instead, Origin re-start fails. Why? .... ci possiamo organizzare per lunedì, anche una video conferenza potrebbe forse aiutare? saluti, per ora Ale -- Alessandro Falaschi http://infocom.uniroma1.it/alef/wiki/pmwiki.php sip:al...@in... sip:aal...@pr... sip:174...@pr... skype:alef.ala msn:aa...@li... aalef_59 su Yahoo alef.ala su Gtalk/Jabber |
|
From: alef <aa...@li...> - 2008-04-27 00:12:16
|
Salve, dopo aver ri-messo su Darwin, sto procedendo a far ri-partire
l'RRDM ed un nodo, per ora Darwin. Con l'occasione dò una ricontrollata
agli script, ed aggiorno il cvs. Scrivo di seguito una sorta di
promemoria
* ho aggiornato i moduli CPAN HTTP-Server-Simple
HTTP-Server-Simple-Static all'ultima versione. Probabilmente, è meglio
farlo anche per gli altri.
* ho capito perché l'installazione dice *sempre* di dover re-installare
questi due moduli: il comando "awk 'BEGIN {FS="-"} {print $1 "::" $2}'"
funziona solo se nel nome del modulo c'è un solo trattino. Ho provato ad
investigare come migliorarlo, ma mi sono arreso per mancanza di tempo.
Riproverò? Ci sono volontari al cimento?
* ho modificato il path del file di configurazione per apache, ma mi
chiedo: non sarebbe meglio evitare di configurarlo quasi alla cieca, ed
invece scrivere a schermo la modifica da fare?
* ho aggiunto il modulo Net-UPnP-1.2.1 tra quelli da caricare
nell'install, che non lo era
* quando lancio il nodo, dato che su labtel ho installato anche vlc, il
suo lo strato di adattamento tenta di usarlo, però si lamenta dicendo
"sh: cannot create tmp/vlc_log: Directory nonexistent". Francesco, pensi
di poter fixare questa cosa? ad esempio, nella installazione?
* ho aggiornato $oCDNpassword con il valore "version8"
* dovrei aver configurato /etc/rc.local in modo che al boot, partano sia
* ho modificato la stampa prodotta alla linea 492 di Node.pm in modo che
non si ripeta così spesso (ossia, ora è node_log ("AuthTokenGlobal
$$reg{AuthTokenGlobal}", 2, 'n');). Però, non vedo nella directory "doc"
aggiornamenti relativi alla autenticazione (ed al UPnP). Mi raccomando
Francesco, ci scriva qualcosa!
Per ora mi fermo qui, prossimamente, una seconda revisione al codice,
che spero di capire :-) E poi, metterò anche io la mia Origin!
Ale
--
Alessandro Falaschi
http://infocom.uniroma1.it/alef/wiki/pmwiki.php
sip:al...@in...
sip:aal...@pr...
sip:174...@pr...
skype:alef.ala
msn:aa...@li...
aalef_59 su Yahoo
alef.ala su Gtalk/Jabber
|
|
From: Francesco O. <fra...@it...> - 2008-02-27 09:54:40
|
Salve a tutti, Il problema fondamentale è che per adesso sono veramente troppi i casi in cui l'origin si riavvia e tira giù tutti i servizi... Forse potremmo iniziare evitando di far fare all'Origin ìil reboot quando si pubblica un nuovo contenuto. In questo modo possiamo almeno ridurre le cause del disservizio. Inoltre stasera verifico anche se quando l'origin si depubblica viene divulgato correttamente un teardown ai nodi. un saluto a tutti Francesco On Tue, 2008-02-26 at 11:23 +0100, alef wrote: > Ieri mi sono incontrato con Francesco, un nuovo sviluppatore di OpenCDN, > che sta procedendo in modo abbastanza spedito alla integrazione di > VideoLAN anche sulle entità-nodo, ed alla soluzione dei problemi > associati alle entità NATtate. Invio questa serie di riflessioni che > sono scaturite dall'incontro anche alla lista di sviluppo, dove spero > avremo modo di aggregare vecchi e nuovi interessati al progetto. > > o o o o o o o o o o o o o o o o o o o o o o o > > ... dopo l'incontro di ieri > > 1) cosa scrivere nella tesi - credo sia l'occasione buona per articolare > una visione prospettica del fenomeno video-via-rete. Come spunti di > riflessione, oltre alle cose di cui stavamo iniziando a discutere sul > finale (a proposito: per la mia lezione di prova di yoga, sono arrivato > in tempo!), consiglio > > 1a) - dare una occhiata ai clip disponibili presso > http://www.sharemedia.it/site/it-IT/default.html, e cliccando su "about > sharemedia". Simpatico per dare una inquadramento dal punto di vista di > chi poi queste cose le vuol vendere, ma anche buono come "vision" sulla > tecnologia > > 1b) - mettere a confronto, per quanto possibile, le architetture linkate > presso la sezione links della pagina di opencdn > (http://labtel.ing.uniroma1.it/opencdn/#links), in particolare current_, > qoob, miro, tribler, joost, babelgum. In particolare, mi è parso di > capire che tribler goda dei favori dei progetti della comunità europea. > Dal canto mio, cercherò di di interagire con qualcuno del progetto p2p > next (www.p2p-next.org/, ma vedi anche cosa esce da google!), che a > quanto pare, ha un affiliato proprio a via eudossiana (delli priscoli) > > 2) tornando agli sviluppi del codice, stavo pensando... che quando una > origin ri-parte, e abbatte tutti i downstream che aveva, da cui > l'esigenza del processo che li riattiva, che tu hai sviluppato > ex-novo... a pensarci bene, il modo più corretto di affrontare questa > specifica circostanza, è che l'Origin, prima di ri-lanciarsi, convinca > l'RRDM a propagare un TEARDOWN per i "Program" che quell'Origin aveva > annunciato. Per questo, l'Origin dovrebbe invocare il metodo Teardown > offerto dall'RRDM, tranne che... > > 2a) riguardando in tutta fretta il codice, vedo che per teardown/setup > non c'è una fase di autenticazione, e questo è perché SetUp e Teardown > possono essere invocati solo dal portale co-residente con l'RRDM, in > base alla configurazione (in etc/RRDMconfig.pm) di > $RRDMconfig::forked_addr (usata alla linea 120 di RRDM.pl) pari a > 127.0.0.1. (incidentalmente, noto un disallineamento del commento > presente in RRDMconfig.pm, rispetto al suo uso effettivo nel codice, > dovrò sistemarlo...) > > 2b) per quanto appena detto, per permettere alle Origin che fanno il > re-boot, di invocare il Teardown, tocca lavorarci un pò. D'altra parte, > mi sto chiedendo (ma non ho più tempo, devo pensare alla lezione di > domani)... possibile che, quando una Origin fa il re-boot, non provveda > prima a de-pubblicare i propri contenuti, e che questo, non determini > presso l'RRDM, il Teardown automatico degli instradamenti in atto per i > Program che si sono de-pubblicati ??? sto leggendo (dopo tantissimo > tempo!) il file di TODO, e non ce lo leggo... > > .... beh ora vi saluto tutti, e colgo l'occasione per fare (a chi non > sentivo da tempo) 1000 auguri di cose buone! Internet Email Confidentiality Footer ----------------------------------------------------------------------------------------------------- La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P., D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. ----------------------------------------------------------------------------------------------------- |
|
From: alef <aa...@li...> - 2008-02-26 10:25:43
|
Ieri mi sono incontrato con Francesco, un nuovo sviluppatore di OpenCDN, che sta procedendo in modo abbastanza spedito alla integrazione di VideoLAN anche sulle entità-nodo, ed alla soluzione dei problemi associati alle entità NATtate. Invio questa serie di riflessioni che sono scaturite dall'incontro anche alla lista di sviluppo, dove spero avremo modo di aggregare vecchi e nuovi interessati al progetto. o o o o o o o o o o o o o o o o o o o o o o o ... dopo l'incontro di ieri 1) cosa scrivere nella tesi - credo sia l'occasione buona per articolare una visione prospettica del fenomeno video-via-rete. Come spunti di riflessione, oltre alle cose di cui stavamo iniziando a discutere sul finale (a proposito: per la mia lezione di prova di yoga, sono arrivato in tempo!), consiglio 1a) - dare una occhiata ai clip disponibili presso http://www.sharemedia.it/site/it-IT/default.html, e cliccando su "about sharemedia". Simpatico per dare una inquadramento dal punto di vista di chi poi queste cose le vuol vendere, ma anche buono come "vision" sulla tecnologia 1b) - mettere a confronto, per quanto possibile, le architetture linkate presso la sezione links della pagina di opencdn (http://labtel.ing.uniroma1.it/opencdn/#links), in particolare current_, qoob, miro, tribler, joost, babelgum. In particolare, mi è parso di capire che tribler goda dei favori dei progetti della comunità europea. Dal canto mio, cercherò di di interagire con qualcuno del progetto p2p next (www.p2p-next.org/, ma vedi anche cosa esce da google!), che a quanto pare, ha un affiliato proprio a via eudossiana (delli priscoli) 2) tornando agli sviluppi del codice, stavo pensando... che quando una origin ri-parte, e abbatte tutti i downstream che aveva, da cui l'esigenza del processo che li riattiva, che tu hai sviluppato ex-novo... a pensarci bene, il modo più corretto di affrontare questa specifica circostanza, è che l'Origin, prima di ri-lanciarsi, convinca l'RRDM a propagare un TEARDOWN per i "Program" che quell'Origin aveva annunciato. Per questo, l'Origin dovrebbe invocare il metodo Teardown offerto dall'RRDM, tranne che... 2a) riguardando in tutta fretta il codice, vedo che per teardown/setup non c'è una fase di autenticazione, e questo è perché SetUp e Teardown possono essere invocati solo dal portale co-residente con l'RRDM, in base alla configurazione (in etc/RRDMconfig.pm) di $RRDMconfig::forked_addr (usata alla linea 120 di RRDM.pl) pari a 127.0.0.1. (incidentalmente, noto un disallineamento del commento presente in RRDMconfig.pm, rispetto al suo uso effettivo nel codice, dovrò sistemarlo...) 2b) per quanto appena detto, per permettere alle Origin che fanno il re-boot, di invocare il Teardown, tocca lavorarci un pò. D'altra parte, mi sto chiedendo (ma non ho più tempo, devo pensare alla lezione di domani)... possibile che, quando una Origin fa il re-boot, non provveda prima a de-pubblicare i propri contenuti, e che questo, non determini presso l'RRDM, il Teardown automatico degli instradamenti in atto per i Program che si sono de-pubblicati ??? sto leggendo (dopo tantissimo tempo!) il file di TODO, e non ce lo leggo... .... beh ora vi saluto tutti, e colgo l'occasione per fare (a chi non sentivo da tempo) 1000 auguri di cose buone! -- Alessandro Falaschi http://infocom.uniroma1.it/alef/wiki/pmwiki.php sip:al...@in... sip:aal...@pr... sip:174...@pr... skype:alef.ala msn:aa...@li... aalef_59 su Yahoo alef.ala su Gtalk/Jabber |
|
From: alef <aa...@li...> - 2007-04-05 14:43:51
|
ovviamente, visto il ritardo con cui rispondo, l'evento sarà gia "andato" :-( Alex Gerelli - Viamatica srl wrote: > Salve, > mi sto avvicinando in questi giorni allo streaming video su linux > (lato server) ed ho trovato il suo nome legato ad un patch per Apple > DSS e VLC. > Brevemente le spiego di quello che ho bisogno e, se ha tempo, mi > piacerebbe sapere se sono sulla strada giusta o meno. In partica ho la > necessita' di mandare in streaming su internet cio' che viene ripreso > da una telecamera in una sala congressi; il video deve essere mandato > su un server (tramite una "normale" ADSL da almeno 512Kb/s in up) e > poi dal server inoltrato a tutti quanti su WEB lo desiderano (sempre > in base al limite della banda disponibile sul server). E' corretto > usare sul server un prodotto come il DSS di Apple? la funzione che > serve a me e' il "reflector"? si. con il reflector, non serve la nostra "patch", bisogna settare VLC per fargli spedire l'RTP direttamente verso DSS, e copiare presso DSS l'SDP che descrive il flusso. Altrimenti, con la nostra patch, DSS fa da Relay, e prende da VLC, che deve essere settato come server RTSP. > Se nella sala congressi ho anche un "semplice" PC con Windows (a cui > e' collegata la telecamera), da quanto capisco posso usare VLC per > preparare ed inviare uno streaming verso il server? tutto questo e' > possibile farlo in "diretta" con l'evento che si riprende, vero? si, in diretta, sennò che live streaming è ? :-) però, è pur vero che la "diretta" è più un fiore all'occhiello, che una vera esigenza degli utenti. Questi, preferiranno senz'altro un video on demand, da poter vedere quando c'è il tempo, e skippare nelle parti più noiose. > > Mi perdoni l'ignoranza, ma ho sempre lavorato negli ultimi 10 anni con > le reti e server mail/web in generale come lavoro, e a livello > amatoriale con i video (a partire da Amiga per finire con una > telecamerina digitale con HD) pero' ora e' venuto il momento di > "unire" queste esperienze! sembra facile :-) > > Grazie, e buon lavoro. > > > Saluti, > Alessandro Gerelli grazie, mi faccia sapere ! > > Quando il Vero Sys-Admin si ferma a fare benzina ad un distributore > IP, si meraviglia di non poterlo usare come server DHCP. > |
|
From: Alessandro F. <al...@in...> - 2006-10-15 17:41:47
|
Trovo questo sito http://www.getdemocracy.com/ molto interessante. Qualcuno lo conosceva ? qualcuno l'ha provato ??? -- Alessandro Falaschi <al...@in...> |
|
From: Neateye <nit...@ao...> - 2005-12-22 23:19:14
|
Call out Gouranga be happy Gouranga Gouranga Gouranga! That which brings the highest happiness... |
|
From: maxxacab <max...@ti...> - 2005-12-15 16:38:28
|
|
From: Alessandro F. <aa...@li...> - 2005-12-04 23:36:47
|
ti leggo solo ora... =E8 che ho un filtro che instrada su di una cartella a parte :-( ok domani vedo di allineare il cfg con la porta giusta, e di aggiornare il nodo su rete GARR con l'ultimo cvs, cos=EC dovremmo poter testare anch= e la feature "PYTE" introdotta per ultima da Piero :-) Alessandro Il giorno lun, 28-11-2005 alle 17:05 +0100, Massimo Aghemo ha scritto: > > > ho verificato che effettivamente il problema era sul nostro FW, che= non > > > lasciava passare le richieste alle listen port dei relay su Helix. > > > Entro la meta' della prossima settimana la configurazione del FW ve= rra' > > > modificata opportunamente e rimettero' finalmente il nostro nodo su > > OpenCDN. >=20 > Mi sono accorto stamattina che il FW non era l'unico problema: > richiedendo il contenuto erogato dalla nostra origin, l'RRDM ritorna l'= url > rtsp://193.206.139.37:10554/broadcast/split0/163.162.16.18:2030/broadca= st/la7.rm >=20 > anziche' (nota la porta 2221 al posto della 2030 su 163.162.16.18) > rtsp://193.206.139.37:10554/broadcast/split0/163.162.16.18:2221/broadca= st/la7.rm >=20 > pare che sul nodo 193.206.139.37 etc/HelixConfig abbia ancora i valori = delle > porte utilizzati nelle versioni precedenti alla 0.7.3, quindi la richie= sta > viene effettuata su una porta diversa da quella su cui e' in ascolto l'= origin. >=20 > Se aggiorni HelixConfig sul nodo penso che tutto dovrebbe andare a post= o. > Purtroppo i valori delle porte utilizzate da Helix per i relay devono e= ssere > identici su tutti i nodi e non possono essere configurati in maniera > centralizzata, ma devono essere impostati su ciascun nodo e su ciascuna= origin. >=20 > Ciao, > Massimo --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
|
From: Massimo A. <m_a...@ya...> - 2005-11-28 16:06:18
|
> > ho verificato che effettivamente il problema era sul nostro FW, che non > > lasciava passare le richieste alle listen port dei relay su Helix. > > Entro la meta' della prossima settimana la configurazione del FW verra' > > modificata opportunamente e rimettero' finalmente il nostro nodo su > OpenCDN. Mi sono accorto stamattina che il FW non era l'unico problema: richiedendo il contenuto erogato dalla nostra origin, l'RRDM ritorna l'url rtsp://193.206.139.37:10554/broadcast/split0/163.162.16.18:2030/broadcast/la7.rm anziche' (nota la porta 2221 al posto della 2030 su 163.162.16.18) rtsp://193.206.139.37:10554/broadcast/split0/163.162.16.18:2221/broadcast/la7.rm pare che sul nodo 193.206.139.37 etc/HelixConfig abbia ancora i valori delle porte utilizzati nelle versioni precedenti alla 0.7.3, quindi la richiesta viene effettuata su una porta diversa da quella su cui e' in ascolto l'origin. Se aggiorni HelixConfig sul nodo penso che tutto dovrebbe andare a posto. Purtroppo i valori delle porte utilizzate da Helix per i relay devono essere identici su tutti i nodi e non possono essere configurati in maniera centralizzata, ma devono essere impostati su ciascun nodo e su ciascuna origin. Ciao, Massimo ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Alessandro F. <aa...@li...> - 2005-11-28 01:10:14
|
ok benissimo :-) io nel frattempo dovrei aver sostituito l'alimentatore di labtel, la cui ventola ci ha ormai lasciati... :-) saluti Il giorno gio, 24-11-2005 alle 15:05 +0100, Massimo Aghemo ha scritto: > > Si, penso che il problema sia del firewall, dato che la redistribuzio= ne > > del feed Helix che arriva dal worshop, invece, funziona bene... (oddi= o, > > 5 min fa funzionava, in questo momento no :-( ). > >=20 > > Purtroppo per=F2 non ti posso aiutare nel troubleshooting del firewal= l, > > dato che sulla, macchina 193.206.139.37, che fa da lasthop nazionale, > > non ho accesso di root, e non posso sniffare :-( >=20 > Ciao Alessandro, > ho verificato che effettivamente il problema era sul nostro FW, che non > lasciava passare le richieste alle listen port dei relay su Helix. > Entro la meta' della prossima settimana la configurazione del FW verra' > modificata opportunamente e rimettero' finalmente il nostro nodo su Ope= nCDN. >=20 > Ciao, > Massimo --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
|
From: Massimo A. <m_a...@ya...> - 2005-11-24 14:07:11
|
> Si, penso che il problema sia del firewall, dato che la redistribuzione > del feed Helix che arriva dal worshop, invece, funziona bene... (oddio, > 5 min fa funzionava, in questo momento no :-( ). > > Purtroppo però non ti posso aiutare nel troubleshooting del firewall, > dato che sulla, macchina 193.206.139.37, che fa da lasthop nazionale, > non ho accesso di root, e non posso sniffare :-( Ciao Alessandro, ho verificato che effettivamente il problema era sul nostro FW, che non lasciava passare le richieste alle listen port dei relay su Helix. Entro la meta' della prossima settimana la configurazione del FW verra' modificata opportunamente e rimettero' finalmente il nostro nodo su OpenCDN. Ciao, Massimo ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Alessandro F. <aa...@li...> - 2005-11-18 09:10:09
|
Si, penso che il problema sia del firewall, dato che la redistribuzione del feed Helix che arriva dal worshop, invece, funziona bene... (oddio, 5 min fa funzionava, in questo momento no :-( ). Purtroppo per=F2 non ti posso aiutare nel troubleshooting del firewall, dato che sulla, macchina 193.206.139.37, che fa da lasthop nazionale, non ho accesso di root, e non posso sniffare :-( Il giorno gio, 17-11-2005 alle 11:52 +0100, Massimo Aghemo ha scritto: > > ... il tuo live feed... non si vede :-(( cio=E8, il "tuo" punto di > > partenza funziona correttamente, ma il relay fatto sul 193.206.139.37 > > no.... ho anche provato il metodo di ieri, di farlo ripartire, ma > > niente :-((( >=20 > non vorrei che il problema dipendesse dal nostro firewall aziendale: se= hai > tempo oggi pomeriggio (mi trovi fino alle 16.30) o domani possiamo fare= qualche > prova. --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
|
From: Massimo A. <m_a...@ya...> - 2005-11-17 10:52:27
|
> ora sto uscendo (per andare al Wsh) e non ho tempo di riflettere, però > mi pare che il problema che descrivi, sia legato alla ambiguità Origin- > FirstHop. Che a sua volta, è legato ad un modello di riferimento > iniziale, in cui l'encoder era co-residente con l'Origin. Alla luce > della nuova direzione di sviluppo, in cui i fornitori di contenuti hanno > solo l'encoder, e lo puntano verso una origin "annidata" entro la core > network, in effetti Origin e FirstHop tendono a coincidere. > > Credo che la soluzione NON dovrebbe essere ricercata nello strato di > adattamento, ma in quelli superiori, in quanto è comune anche a Darwin. > Ma nella fretta, non vorrei dire stupidaggini :-) Tutto sta a capire, se > la modifica poi non comporti altri problemi collaterali.... La posizione dell'encoder non mi sembra che sia rilevante: credo che la causa del problema sia soltanto la presenza sul medesimo nodo di Origin e FH. Hai ragione sul fatto che non e' solo un problema di Helix.pm: ho provato con Darwin e' ho visto che capita la stessa cosa (relay verso se' stesso). Senz'altro la soluzione e' da cercare nei livelli superiori a quelli di adattamento, ma nel caso questa via non fosse percorribile penso che si potrebbe limitare il problema a livello di adaptation layer. > ... il tuo live feed... non si vede :-(( cioè, il "tuo" punto di > partenza funziona correttamente, ma il relay fatto sul 193.206.139.37 > no.... ho anche provato il metodo di ieri, di farlo ripartire, ma > niente :-((( non vorrei che il problema dipendesse dal nostro firewall aziendale: se hai tempo oggi pomeriggio (mi trovi fino alle 16.30) o domani possiamo fare qualche prova. Ciao, Massimo ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Alessandro F. <al...@in...> - 2005-11-17 07:44:56
|
Si, me ne ero accorto anche io :-( ma non ci avevo dato peso.. in definitiva per i miei sviluppi, uso dummy.pm, e configuro diversi nodi su di una stessa macchina, per cui ero un p=F2 abituato ad indirizzi un p= =F2 annodati. ora sto uscendo (per andare al Wsh) e non ho tempo di riflettere, per=F2 mi pare che il problema che descrivi, sia legato alla ambiguit=E0 Origin- FirstHop. Che a sua volta, =E8 legato ad un modello di riferimento iniziale, in cui l'encoder era co-residente con l'Origin. Alla luce della nuova direzione di sviluppo, in cui i fornitori di contenuti hanno solo l'encoder, e lo puntano verso una origin "annidata" entro la core network, in effetti Origin e FirstHop tendono a coincidere. Credo che la soluzione NON dovrebbe essere ricercata nello strato di adattamento, ma in quelli superiori, in quanto =E8 comune anche a Darwin. Ma nella fretta, non vorrei dire stupidaggini :-) Tutto sta a capire, se la modifica poi non comporti altri problemi collaterali.... ... il tuo live feed... non si vede :-(( cio=E8, il "tuo" punto di partenza funziona correttamente, ma il relay fatto sul 193.206.139.37 no.... ho anche provato il metodo di ieri, di farlo ripartire, ma niente :-((( a questo punto, mi sa che va finire che quello che funzioner=E0 meglio, =E8 proprio l'adattamento per Windows... mi dicono che ha una API Soap per il controllo remoto, che non dovrebbe fallire :-( a dopo Alessandro Il giorno mer, 16-11-2005 alle 17:33 +0100, Massimo Aghemo ha scritto: > Ciao Alessandro, > ho messo in piedi un'origin con uno stream live. > Facendo qualche prova mi sono accorto di un problema: > quando l'origin funziona anche come nodo, Helix.pm configura il server = Helix > come per fare un relay con se stesso, ottenendo un'URL come questa: >=20 > rtsp://193.206.139.37:10554/broadcast/split0/151.100.122.171:2030/broad= cast/split1/151.100.122.171:2221/broadcast/garr.rm >=20 > Cio' non impedisce allo stream di funzionare, ma senz'altro non e' un > comportamento desiderabile, in quanto le URL diventano inutilmente lung= he e > appesantiscono la configurazione del server Helix. >=20 > Domani cerchero' di correggere questo comportamento. >=20 > A presto, > Massimo >=20 >=20 >=20 >=20 > =09 >=20 > =09 > =09 > ___________________________________=20 > Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB=20 > http://mail.yahoo.it --=20 Alessandro Falaschi <al...@in...> |
|
From: Massimo A. <m_a...@ya...> - 2005-11-14 09:53:11
|
> 1) - si ma se "io" ho un live feed da immettere in OpenCDN, e non voglio > installare nulla di OpenCDN, e dispongo dell'enconder di VLC (VideoLAN), > che devo fare ?? lo posso fare?? Questo sviluppo mi sembra molto interessante. Sarebbe molto utile se un content provider munito solo di un encoder (non solo VLC, ma anche Helix Mobile Producer, Real Producer, Windows Media Encoder) potesse fornire contenuti a OpenCDN senza dover necessariamente gestirne un nodo. Proprio in questi giorni sto cercando di mettere in piedi un sistema del genere che funzioni almeno per Helix Mobile Producer e possibilmente anche per Windows Media Encoder. > 2) - ma se tutti i presenti fanno streaming Windows Media, ed è quello > ciò che serve, che senso ha perfezionare lo sviluppo di Darwin ed > Helix ??? > > ..... i miei tentativi di rispondere "ma è un progetto OpenSource, siete > tutti benvenuti a contribuire" sono caduti più o meno nel vuoto... il > fatto è che quello è un contesto in cui i partecipanti raccontano ciò > che sviluppano per i propri fini, e che possa essere riusabile da > altri... poco spazio per la collaborazione :-( > > quindi, per il caso 1) ... non dovrebbe essere difficilissimo... in > particolare, visto che l'encoder mpeg4ip (mp4live) non gira più "senza > modifiche" con fedora core 3... vedrò di occuparmene in fretta. Per il > caso 2)... la vedo più dura, sto facendo una analisi di ciò che serve di > fare, ma veramente, nessuno si offre ??? Sinceramente mi sarebbe piaciuto provare a portare OpenCDN sotto Windows e scrivere l'adaptation layer per Windows Media Server, pero' al momento non ho il tempo materiale di provarci. Spero davvero che qualcuno ci provi (e sono disponibile a dare supporto per test e debugging), perche' la mancanza del supporto di Windows Media Server e' senza dubbio la lacuna principale di OpenCDN e la maggior fonte di obiezioni durante le presentazioni. Ciao, Massimo ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Alessandro F. <al...@in...> - 2005-11-10 12:09:18
|
Carissimo Maurizio, leggo sulla mailing list "netcast" che sar=E0 il tuo gruppo a provvedere allo streaming della conferenza GARR (http://www.garr.it/ws6/index.htm), e da parte mia, penso sia una buona opportunit=E0 per provare gli ultimi aggiornamenti del codice, il cui supporto ad Helix =E8 ancora migliorato, grazie al lavoro svolto da Massimo Aghemo (in copia). ora ti ho chiamato allo 06 499xxx36, 335 71yyy66, ma non ti trovo :- ( stufo delle email, credo convenga sentirsi!!!! l'unica mia perplessit=E0, =E8 che il "nodo" OpenCDN equipaggiato con Hel= ix, da cui OpenCDN potrebbe prelevare il feed, sarebbe il tuo, e su quello, dovrebbe girare appunto anche l'entit=E0-demone perl "nodo OpenCDN", che interagisce con Helix, configurandogli il transmitter. Senza fare dei test prima, non me la sento di garantire l'indipendenza di questa configurazione, rispetto ad un uso "di produzione" dello stesso tuo Helix server, ed a tale riguardo, vorrei anche ricevere l'autorevole parere di Massimo. Ma se riuscissimo, sarebbe il primo caso di un test reale, in quanto forse, anche Giorgetti di Trieste, potrebbe metter su un nodo di replica, e questi nodi di replica, alleggerirebbero il carico del tuo. Leggo poi che Franca annuncia la disponibilit=E0 alla codifica Mpeg4 +Darwin. Anche qui, vale lo stesso discorso di prima, forse un minimo meno problematico. In quel caso infatti, il "primo" Darwin che eroga il contenuto, non ha bisogno di ospitare necessariamente una entit=E0 OpenCDN; in tutti i modi, avrei bisogno di sapere in anticipo, su che macchina si trova, e con che mount point :-) speriamo di riuscire a fare qualcosa di buono :-) saluti cordiali! --=20 Alessandro Falaschi <al...@in...> |
|
From: Alessandro F. <aa...@li...> - 2005-11-10 11:08:39
|
Benissimo, un bel passo avanti!!!! nei prossimi giorni tester=F2 la nuova feature PYTE.. che comunque ha ancora bisogno di qualche aggiustamento per trattare il caso in cui non tutte le entit=E0 siano "d'accordo" se funzionare in modo "pyte" o meno.... ma di questo abbiam gi=E0 parlato con PierLuigi. nel frattempo, sono stato al meeting della TF-VVC di terena (http://www.terena.nl/tech/task-forces/tf-vvc/ ) e, per ci=F2 che riguard= a OpenCDN, posso anticipare che le principale obiezioni (!) sono state: 1) - si ma se "io" ho un live feed da immettere in OpenCDN, e non voglio installare nulla di OpenCDN, e dispongo dell'enconder di VLC (VideoLAN), che devo fare ?? lo posso fare?? 2) - ma se tutti i presenti fanno streaming Windows Media, ed =E8 quello ci=F2 che serve, che senso ha perfezionare lo sviluppo di Darwin ed Helix ??? ..... i miei tentativi di rispondere "ma =E8 un progetto OpenSource, siet= e tutti benvenuti a contribuire" sono caduti pi=F9 o meno nel vuoto... il fatto =E8 che quello =E8 un contesto in cui i partecipanti raccontano ci=F2 che sviluppano per i propri fini, e che possa essere riusabile da altri... poco spazio per la collaborazione :-( quindi, per il caso 1) ... non dovrebbe essere difficilissimo... in particolare, visto che l'encoder mpeg4ip (mp4live) non gira pi=F9 "senza modifiche" con fedora core 3... vedr=F2 di occuparmene in fretta. Per il caso 2)... la vedo pi=F9 dura, sto facendo una analisi di ci=F2 che serve= di fare, ma veramente, nessuno si offre ??? Alessandro Il giorno lun, 07-11-2005 alle 20:24 +0100, Pierluigi Vittori ha scritto: > Salve a tutti, >=20 > ho mandato in CVS una prima versione di PYTE, un nuovo metodo per fare = il > probing dei nodi. >=20 > Quando PYTE viene abilitato, tramite la nuova variabile $use_pyte in > CommConf.pm (non settata di default), =E8 il viewer stesso che fa il pr= obing dei > nodi che gli vengono "segnalati" dall'RRDM. > Quando infatti il viewer si collega al portale, parte una richiesta all= 'RRDM > che restituisce una lista di nodi che hanno il viewer nelle loro footpr= int > dichiarate. >=20 > Per ogni nodo interessato il portale mette quindi, nella pagina html pr= esentata > al viewer, un link ad una immagine, presente sul nodo stesso, che viene= servita > da un nuovo server http presente in ognuno dei nodi. > Il server http calcola l'RTT impegato dal viewer per scaricare l'immagi= ne e lo > memorizza. >=20 > Al momento del setup, l'RRDM chiede a tutti i nodi coinvolti di comunic= are il > tempo di download per quel particolare viewer e il tempo minore, ovviam= ente, =E8 > quello che vince e viene infine fatto il DoRelay. >=20 > In questo modo, diversamente da prima, non vince il primo nodo che risp= onde ma > quello che =E8 pi=F9 vicino al viewer, almeno in termini di RTT, e ques= to dovrebbe > consentire una migliore distribuzione del traffico. >=20 > Gli esperimenti e le prove vanno avanti... :-) >=20 >=20 > Saluti, > Pierluigi >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Dow= nload > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > 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: Pierluigi V. <p.v...@ra...> - 2005-11-07 19:25:00
|
Salve a tutti, ho mandato in CVS una prima versione di PYTE, un nuovo metodo per fare il probing dei nodi. Quando PYTE viene abilitato, tramite la nuova variabile $use_pyte in CommConf.pm (non settata di default), =E8 il viewer stesso che fa il prob= ing dei nodi che gli vengono "segnalati" dall'RRDM. Quando infatti il viewer si collega al portale, parte una richiesta all'R= RDM che restituisce una lista di nodi che hanno il viewer nelle loro footprin= t dichiarate. Per ogni nodo interessato il portale mette quindi, nella pagina html pres= entata al viewer, un link ad una immagine, presente sul nodo stesso, che viene s= ervita da un nuovo server http presente in ognuno dei nodi. Il server http calcola l'RTT impegato dal viewer per scaricare l'immagine= e lo memorizza. Al momento del setup, l'RRDM chiede a tutti i nodi coinvolti di comunicar= e il tempo di download per quel particolare viewer e il tempo minore, ovviamen= te, =E8 quello che vince e viene infine fatto il DoRelay. In questo modo, diversamente da prima, non vince il primo nodo che rispon= de ma quello che =E8 pi=F9 vicino al viewer, almeno in termini di RTT, e questo= dovrebbe consentire una migliore distribuzione del traffico. Gli esperimenti e le prove vanno avanti... :-) Saluti, Pierluigi |
|
From: Alessandro F. <aa...@li...> - 2005-09-28 22:48:35
|
Il giorno mar, 27-09-2005 alle 12:04 +0200, Massimo Aghemo ha scritto: > Ho testato l'ultima versione CVS sia con Dummy che con Helix+Darwin e m= i sembra > che fili tutto liscio.=20 bene :-) io ho corretto un bug facile ma non visto prima.... > Spero che con le ultime modifiche l'adaptation layer Helix sia ora > sufficientemente stabile da poter essere incluso in una nuova release. appena posso metto su l'ultima versione, e preparo il rilascio > PS. Ho fatto l'upgrade a Darwin 5.5: su solaris 8 funziona bene, ma su = solaris > 9 mi sta creando parecchi problemi (occupa tutta la memoria virtuale). Sul mio linux fedora 3 sembra che vada... ah! oggi ho comperato Linux&Co in edicola, su di un DVD c'=E8 anche OpenSolaris! --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
|
From: Massimo A. <m_a...@ya...> - 2005-09-27 10:04:43
|
> uh.. non ho visto i messaggi di errore, ed ora non ho tempo di > riprodurre la soluzione perchè sto uscendo.. > proverò, però la situazione > attuale non mi convince troppo :-( > > Adesso, quando Node.pm termina, chiama Adaptation::clean_relay anzichè > NodeLib::clean_relay come faceva prima. Quindi, se Adaptation è > Dummy.pm, torna felice senza fare nulla, mentre invece Meta... torna a > chiamare NodeLib::clean_relay, in pratica "tornando indietro" ! Se poi > indago in cosa c'è scritto in NodeLib::clean_relay, a prima vista > sembrerebbe che la chiamata Adaptation::no_relay non dovrebbe causare > problemi, dato che viene eseguita appunto da Dummy o da Meta... ok > proverò stasera!!! ho appena fatto il commit per correggere l'ultimo baco che ho trovato su Helix.pm (non ripuliva correttamente la configurazione quando c'erano anche dei relay Darwin). Ho testato l'ultima versione CVS sia con Dummy che con Helix+Darwin e mi sembra che fili tutto liscio. Anche il meccanismo per la pulizia dei relay funziona correttamente in tutti i casi che ho provato. Spero che con le ultime modifiche l'adaptation layer Helix sia ora sufficientemente stabile da poter essere incluso in una nuova release. Ciao, Massimo PS. Ho fatto l'upgrade a Darwin 5.5: su solaris 8 funziona bene, ma su solaris 9 mi sta creando parecchi problemi (occupa tutta la memoria virtuale). ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Alessandro F. <aa...@li...> - 2005-09-27 09:08:07
|
Il giorno gio, 22-09-2005 alle 18:17 +0200, Massimo Aghemo ha scritto: > Hai ragione, il fatto che usando Dummy.pm i log risultino sporcati da m= essaggi > relativi a Helix indica che il codice che effettua le inizializzazioni = in Helix > per le Origin non si trova nel posto giusto: l'ho spostato in una nuova > funzione "origin_config". Non l'ho inserito in set_RTSP_credentials() p= erch=E9 > altrimenti sarebbe stato eseguito ogni volta che viene eseguita la funz= ione > "transit". sto vedendo.. quindi ora in Origin.pm c'=E8 la chiamata ad Adaptation::origin_config, che in Dummy.pm torna felice, mentre in Meta.pm viene chiamata Helix::origin_config, solo se c'=E9 Helix... ok mi sta bene. Devo ricordarmi di modificare doc/README.adaptation documentando la nuova sub Adaptation::origin_config > Questo mi pare abbia risolto i problemi all'avvio, ma ho notato che qua= ndo si > abbatte un nodo la funzione clean_relays cerca di sconfigurare i relay = che sono > stati configurati e questo genera dei messaggi di errore: non ho ancora= avuto > il tempo di provare a risolvere il problema. uh.. non ho visto i messaggi di errore, ed ora non ho tempo di riprodurre la soluzione perch=E8 sto uscendo.. prover=F2, per=F2 la situa= zione attuale non mi convince troppo :-( Adesso, quando Node.pm termina, chiama Adaptation::clean_relay anzich=E8 NodeLib::clean_relay come faceva prima. Quindi, se Adaptation =E8 Dummy.pm, torna felice senza fare nulla, mentre invece Meta... torna a chiamare NodeLib::clean_relay, in pratica "tornando indietro" ! Se poi indago in cosa c'=E8 scritto in NodeLib::clean_relay, a prima vista sembrerebbe che la chiamata Adaptation::no_relay non dovrebbe causare problemi, dato che viene eseguita appunto da Dummy o da Meta... ok prover=F2 stasera!!! --=20 Alessandro Falaschi - aa...@li... MSN: aa...@li... ICQ: 156691142 Yahoo: aalef_59 Jabber: aal...@ja... |
|
From: Massimo A. <m_a...@ya...> - 2005-09-23 10:12:36
|
> Questo mi pare abbia risolto i problemi all'avvio, ma ho notato che quando si > abbatte un nodo la funzione clean_relays cerca di sconfigurare i relay che > sono > stati configurati e questo genera dei messaggi di errore: non ho ancora avuto > il tempo di provare a risolvere il problema. Ho spostato l'invocazione di NodeLib::clean_relays nell'adaptation layer, così il Dummy layer non ha più problemi allo shutdown del nodo > Inoltre ho dovuto fare una correzione alle modifiche che hai apportato a > NodeLib.pm perché non funzionavano più i relay con porta RTSP diversa da > quella > standard. Veniva utilizzata una variabile $RTSP che non era stata definita > (credo al posto di $RTSPport). Se la cosa determina problemi, fammi sapere. > Sto cercando di fare il commit dei file modificati, ma ho dei problemi con il > CVS. Ho dovuto fare un'ulteriore modifica a Dummy.pm che inseriva le RTSP port utilizzate mettendoci i due punti davanti. Ora mi sembra che sia con Meta.pm che con Dummy.pm le porte vengano gestite correttamente. Ciao, Massimo ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
