Newsgroup: it.comp.macintosh
Titolo: Re: [OT] A proposito dei download manager...

 cosi` i furbi scaricheranno meglio... bloccando tutti.
ma perche' non 200 
o 2000?
(tanto e' ben noto che chi lo fa e' solo per *ottimizzare* il
funzionamento della rete e che se tutti lo facessero staremmo tutti
molto meglio)

 cosi` i furbi scaricheranno meglio... bloccando tutti.
Quando misi sul mio spazio Web un video del Venerandi, un bastardo mi
buttò a terra il sito saturando la banda e il tetto del traffico (2GB al
mese) con una sfilza di ridownload del file: sicuramente usò dolosamente
un DL...
-- 
Brave your heart / Renounce your fears
Locked away inside / All these years
http://www.cieloprovvisorio.net

NON si scarica 'na sega.
confermo, con connessione umts,safari e z1010 sono costretto ad usare
igetter, altrimenti safari interrompe sempre il download...in tutti
gli altri casi non uso alcun download manager..
Quello che bramerei  pero' comprendere e' perche' senza igetter, non
scarico nulla, anche l'aggiornamento software risulta impossibile (si
interrompe sempre), mentre non ho nessun problema nella navigazione
web..
Inoltre quando scarico con igetter il downlod, oltre a non
interrompersi, risulta a piena banda umts...
problemi di latenza?
grazie dell'attenzione
Mario

 una grinza.
la stabilita' non ha nulla a che vedere con il numero di connessioni
contemporanee

 salvarse/scaricare qualsivogli file dallo shareware al pdf.
con vodafone va un po meglio, da safari ho scricato anche un file di 30
mega (ha fatto il resume 3-4 volte)
ad ogni modo nessuno obietta sull'uso dei DM con 1 sola connessione per
volta, l'obiezione e' al moltiplicarsi delle connessione, certo che se
sto iGetter mette 5 connessioni di defolt so stronzetti mica poco 

 nota al margine: d/load interrotto, e ripreso alla perfezione. Con curl.
Se li interrompo Safari li fa ripartire "chiudendoli" prima: ho piu'
.dmg
inutili, sull'HD, che file. :-)
-- 
me

 cosi` i furbi scaricheranno meglio... bloccando tutti.
Al di là di giudizi morali, non vedo comunque un'azione illeggittima. 
Giuseppe parla anche di saturazione di banda, ha ragione a definirlo
atto doloso, ma se un file è in download, farlo anche 10000 volte non mi
sembra un crimine.
-- 
 
www.filacchione.it
 
 "La democrazia è laica o non esiste."

 Infatti non ho mai parlato di "illegittimita`", semmai di immoralita`.
Sì, facevo un discorso in generale. Personalmente posiziono i d/l
manager un gradino *sotto* gli spyware :)


 wrote:

Confermo: ho Vodafone UMTS "30 ore in libertà" (libertà condizionata,
sottointeso): gli aggiornamenti meli devo scaricare direttamente dal
sito Apple perchè con l'apposita opzione dal Menù Mela la connessione mi
parte. Inoltre capita spesso che nei primi due minuti di navigazione la
connessione sia piuttosto veloce in download e web surfing, minuti dopo
i quali segue una tragica immobilità totale: Safari non carica/scarica
nulla, idem per Soup ed a volte anche Mail. Gli unici programmi che
funziano sempre anche in questi casi sono Adium, iChat e Limewire
(quest'ultimo è davvero inarrestabile: non me ne intendo ma potrebbe
darsi il caso che quelli della Vodafone non "controllino" ancora le
porte che usa Lime?).
La grandissima fregatura è che nei casi di blocco non c'è nulla da fare
se non interrompere la connessione e riavviarla e dal momento che
l'abbonamento UMTS funziona a sessioni di 15 minuti, interrompere una
sessione dopo 3 minuti di navigazione comporta un addebbito equivalente
ad una sessione da 15 minuti.
---
Francesco


 cosi` i furbi scaricheranno meglio... bloccando tutti.
Aggiornamento relativo all'uso di molteplici connessioni contemporanee:
ho sollevato il problema stasera alla bevuta settimanale del giovedi` (e
questa settimana offrivano quelli del gruppo Site Reliability, per cui
si marciava a whisky di vari tipi, ma spero che questo non abbia troppo
influenzato la qualita` del dibattito;-).  Risultato che mi ha stupito:
profondo dissenso fra gli esperti.  Tutti d'accordo sullo scenario
_teorico_ delle "long fat pipes": in quel caso, finche` si usa il TCP di
oggi, "affettare" la banda per ridurre il prodotto banda*ritardo entro
limiti umani ha sostanziali vantaggi -- ma tutti d'accordo anche che non
e` una situazione che si presenti nella realta` di Internet aperta.
Il dissenso: circa 60% sostengono che non ci possono essere vantaggi;
circa 40% invece dicono che possono esserci benissimo, sulla base del
seguente scenario.  Se "ogni tanto" si perde un pacchetto, la
connessione su cui il pacchetto si e` perso viene penalizzata
pesantemente, a volte in maniera selvaggia -- ad esempio, se si perde
anche un solo pacchetto, la connessione potrebbe non tornare "a banda
piena" per VARI secondi (dipende dagli esatti parametri dei vari
apparati che stanno in mezzo -- router, firewall, e via elencando --
piu` ancora che dal cliente e dal server).  Se divido la banda per
cinque, quando capita la perdita di un pacchetto capita su UNA delle
connessioni, quindi il transitorio di (boh) cinque secondi prima che la
connessione torni "a banda piena" tocca solo il 20% della banda che sto
usando, il restante 80% resta intonso.
Diciamo che si perde un pacchetto ogni 10 secondi, causando (sulla
connessione su cui s'e` perso) un transitorio di 5 secondi nel quale la
banda su quella connessione e` complessivamente dimezzata (facendo
l'integrale nel tempo).  Se ho una connessione sola, ho cinque secondi
di banda piena e cinque dimezzata, nel complesso un 75%; se ho cinque
connessioni ciascuna delle quali ha il 20% quando e` "piena", allora nel
corso dei miei 10 secondi sto usando complessivamente il 95% della mia
banda massima teorica.
Nel corso dei 5 secondi problematici, c'e` inoltre un carico
supplementare sul server, che deve tenere i buffer di tutto quello che
e` gia` stato spedito ma ancora non ha ricevuto un ACK; anche questo
carico di memoria di kernel e` ridotto ad 1/5 se le connessioni sono 5,
ciascuna al 20% della banda totale disponibile.
Questo e` il ragionamento dei 40%, che e` molto semplice e lineare
(avendo un minimo di conoscenza di TCP, ovvio) e spero di avere
riportato in modo semplice ma corretto.  Gli altri 60%, per meta`
nicchiano senza argomentare, o se no tirano fuori il TCP Congestion
Control e le differenze fra gli algoritmi di Van Jacobson e di (??? non
ho neppure capito il nome), calorosamente disputati dagli altri; me ne
sono andato che due stavano argomentando in russo, giuro... Fra gli
argomenti non puramente e squisitamente tecnici portati dal 30%
contrario ma piu` che altro "nicchiante": ne` rsync ne` wget prevedono
l'opzione di usare molteplici socket, se il vantaggio ci fosse, la
prevederebbero.
Ah, e uno stava scribacchiando su un tovagliolino di carta per trovare
il numero ottimale di connessioni in funzione della larghezza di banda,
del ritardo, e della probabilita` di perdita di pacchetti (non so se
ipotizzando distribuzione di Poisson, o piu` realistici "burst";-). Mi
sembra intuitivamente chiaro che le prestazioni debbano avere un massimo
attorno a un certo numero di connessioni N (magari N e` 1, ancora non ne
sono certo, continuero` ad esplorare!-).
Ah, su una cosa l'unanimita`: hanno *tutti* ridicolizzato l'idea che un
server che limita la banda per connessione abbia _qualsivoglia_ problema
a riconoscere che N connessioni vengono dallo stesso IP, dividendo fra
loro la banda che il server vuol dedicare a un singolo IP (o, anche piu`
semplice, rifiutare altre connessioni da un dato IP se ce n'e` una gia`
attiva su quell'IP; devo ammettere che questa sarebbe assolutamente
banale da implementare, pensando come programmatore che, come dicevo, di
server TCP ne ha scritti tanti;-).
Quindi, a sentir loro, la possibilita` che un DM multiconnessione vada
piu` veloce perche` "frega" il server e` nulla.  O non va piu` veloce
per nulla, e la ragione per cui i DM hanno tutti l'opzione di
multiconnessione (salvo wget, se vuoi considerarlo un DM;-) e` puramente
"di marketing" dei DM stessi; o, se va piu` veloce, lo fa senza danno
per il server (anzi, con un numero di connessioni modesto ma > 1,
eventualmente un piccolo beneficio in termini di uso della memoria che
il kernel riserva come buffer TCP).
Come dicevo, continuero` a chiedere lumi, magari a quei due o tre
luminari piu` eccelsi che stasera putacaso non c'erano (e magari in
atmosfera meno alcolica;-).
Se non altro, mi pare confermato che la situazione tecnica non sia per
nulla cosi` ovvia e lampante come pare sembrare a te e a Uliano; per la
verita` la grande maggioranza dei contendenti stasera erano certissimi
della propria tesi, ma visto che sono tutte persone di enorme spessore
tecnico ed esperienza idem, e le tesi di cui erano certissimi sono
diverse, io resto super partes a sostenere che non e` cosi` semplice
come puo` sembrare.  Mi e` piaciuto molto, comunque, il fatto che sia
stata totalmente e unanimemente smantellata la tesi, di cui pare invece
che tu e Uliano siate certi, che l'uso del DM multiconnessione, se
guadagna, guadagna "imbrogliando", danneggiando altri utenti e/o il
server: i dubbi tecnici che restano e` se guadagna qualcosa, o nulla, ma
sicuramente non imbroglia e non danneggia nessuno.
Alex

 wrote:
   ...
mi e` venuto in mente di usare anche un po' di sano empirismo. Che io
sappia, 
www.aleax.it
 non impone nessun "limite di banda per connessione"
(se lo fa il fornitore che me lo ospita, certo non lo ha scritto nel
contratto per cui lo pago...!-).  Ho scaricato iGetter e ho provato due
volte a prendere un file di 16MB da 
www.aleax.it
.  La prima volta, con 6
connessioni simultanee, ci ho messo appena meno di 100 secondi.  La
seconda volta, ridotte le connessioni simultanee ammessa a una sola, ho
interrotto il download, con il file a 1/3, dopo quasi 5 minuti.
Ovviamente si possono fare molte altre prove, ecc ecc; i risultati mi
sembrano persino troppo estremi, oltre che parziali ecc.  Ma il
vantaggio e` clamoroso.
Chi ho fregato, chi ho imbrogliato, per accelerare cosi` tanto questo
download?  Dubito che ci siano miriadi di utenti che affollano
www.aleax.it
 alle sette del mattino, ora italiana... o non sara` che,
con un percorso internet lungo e tortuoso da qui al mio sito (*), e
latenze del round-trip assai sostanziali nonostante la buona banda
disponibile (**), la teoria delle long fat pipes si applica eccome, e
cosi` pure quella del dividere la banda per minimizzare l'impatto di
ciascun packet smarrito...?
(*) traceroute mi mostrava gia` 30 hop, di qui gli ultimi 15 tutti "* *
*", quando l'ho interrotto
(**) le ultime latenze che vedo con traceroute sono >200 millisecondi, e
questo e` dopo solo una quindicina di hop... ping neppure risponde, mi
arriva solo qualche "From 
host198-8.pool82184.interbusiness.it
(82.184.8.198) icmp_seq=30 Packet filtered"...
Alex

 sono andato che due stavano argomentando in russo, giuro...
... la cosa strana è che nessuno dei due era russo, ma il whisky era
sicuramente ottimo! :-D
Io comunque sarei stato nel 40% (il whisky non mi garba).
-- 
Per contattarmi:
http://formmailto.com/saltydog

 ho sollevato il problema stasera alla bevuta settimanale del giovedi`
<snip>
socc... ma solo io e i miei amici quando troviamo insieme per bere
parliamo di figa? :#)
-- 
Matteo L
for mail messages sum 36+36

 Io comunque sarei stato nel 40% (il whisky non mi garba).
Quello irlandese e` piuttosto interessante, non lo conoscevo ma col
fatto di avere una sede a Dublino di irlandesi di passaggio qui a
Mountain View di solito ce n'e` un tot.
Alex

 parliamo di figa? :#)
Beh, in un gruppo misto (circa 1/4 dei presenti essendo donne) e` piu`
difficile che la conversazione giri in quella direzione, che poi sarebbe
comunque inappropriata per un luogo di lavoro (la bevuta settimanale e`
una tradizione, non ufficiale ma popolare, che vari gruppi di Googlers
tengono al Googleplex -- nelle terrazze o giardini se e` bel tempo, se
no negli ampi spazi "tipo salotto" entro i locali di Google).
Alex

 dove li hai visti smantellati? Parlo di remore morali, non legali.
Come sopra: *SE* il server volesse impedire l'uso di DM
multiconnessioni, lo fa e basta; se il server "affetta" la banda (in
connessioni ciascuna con banda di non piu` di X), senza impedire l'uso
molteplici connessioni dallo stesso IP, l'unica spiegazione e` che il
gestore del server concordi con la tesi che molteplici connessioni,
ciascuna a banda piu` stretta, sono superiori a una sola connessione cui
venga dedicata tutta la banda disponibile -- sulla base dello scenario
che ho spiegato in dettaglio nel post.
D'altronde, come altro si spiega il fatto empirico (dall'altro mio post)
che scaricando da 
www.aleax.it
, che *NON* impone (per quel che ne so io,
e visto che il server e` mio, dovrei saperlo, no?-) alcun limite, da qui
vado 5-6 volte piu` svelto con un download segmentato su 6 connessioni
che non con una connessione unica?  L'ho provato in un orario che
rendeva molto improbabile l'esistenza di grosse code di utenti sul sito
(e ho intenzione di sperimentare ancora in orari che rendono ancora meno
verosimile l'ipotesi di "tanti utenti in coda al sito", tipo le 4-5 del
mattino ora italiana; da qui non e` arduo;-).  Che "remore morali"
dovrei avere?  Pago dal lato server per "banda illimitata 'best-effort'
(non garantita)", pago dal lato client per una connessione da molteplici
megabit/secondo via cavo, a chi sto "rubando" checchessia?
Se l'eventualita` che i DM multiconnessioni dispiacciano al sito ma non
vengano impediti e` rara, l'eventuale sito che per ragioni sue non puo`
o non vuole bloccare le connessioni multiple, ma non le desidera
comunque, non ha che da dirlo, e ovviamente rispettero` la richiesta di
usare una connessione sola; non vedo ragione di dover usare il default
*opposto*, dando per scontato che i DM multiconnessioni sono
problematici se non esplicitamente consigliati, sulla base di tutte le
considerazioni tecniche e non svolte sinora.  Naturalmente resto aperto
a discorsi tecnici che mi spieghino perche` le cose non stanno cosi`, ma
ancora devo sentirne: sento solo "diktat morali" accompagnati da
"handwaving" che tecnicamente non mi convince... e non mi spiega le mie,
sinora limitate, osservazioni empiriche, tra l'altro;-).
Alex

 difficile che la conversazione giri in quella direzione
aaah beh, questo spiega tutto! :#)


 piu` veloce perche` "frega" il server e` nulla.
il limite di banda puo' essere la connessione di quel server ed e' un
limite hard
il server equipartisce il carico sulle n connessioni, chi ne prende di
piu' scarica piu' in fretta
se non truffano il server fregano cmq quelli che ne hanno una sola
la guerra a chi apre piu' connessioni al limite di infinito per
scaricare piu' in fretta mi pare assai ridicola

 "considerazioni", non "diktat".
OK, sia le une sia gli altri, da diverse persone;-) -- ma basate in ambo
i casi su considerazioni tecniche non approfondite ne` ben basate, a
quanto ho visto sinora.  Se la realta` tecnica e` che in genere l'uso di
connessioni multiple va meglio dell'uso della connessione unica con
tutta la banda a disposizione, diktat e considerazioni si rivelerebbero
entrambi infondati...
Alex

 Qui a Palo Alto
Scusa se ne approfitto: ai primi di agosto sono lě per delle gare a
Stanford, hai delle dritte tipo agenzie o link per affittare un
appartamento o simile nei dintorni per una settimana?
-- 
The only easy day was yesterday
Kaboom?
Yes, Rico. Kaboom.

 parliamo di figa? :#)
anche io e i miei amici, ma fra aperitivo, cena, dopo-cena, arriviamo a
mezzanotte (quando il resto del mondo si anima) già satolli. Stasera si
prevede altra uscita only-men, l'unica donzella estranea ha altre
preferenze sessuali e l'abbiamo chiamata apposta, così possiamo lo
stesso parlare di figa e c'è anche "l'esperto" :-)
-- 
And I'm alive, and I'm alone,
and I've never wanted to be either of those

 scaricare piu' in fretta mi pare assai ridicola
Il "limite di infinito" e` sicuramente ridicolo, come accenni, perche` i
benefici della N+1-esima connessione calano con N.  Vedi ad esempio il
calcolo che facevo relativamente all'ipotesi (ragionevole!) che ogni
tanto si perda un pacchetto, occorra un retransmit, e la connessione in
questione si trovi throttled per parecchi secondi; passare da 1
connessione a 4 porta grandi benefici, da 4 a 16 i benefici sono molto
meno.  Secondo me c'e` in tutta probabilita` un vantaggio (senza danni a
nessuno) per un piccolo numero di connessioni, da qualche parte attorno
alle 4-5 connessioni o giu` di li`.
Poi ovviamente si puo` fare molto, molto meglio (di nuovo, senza danni
per nessuno) se iGetter trova molteplici mirror del file e distribuisce
il carico fra essi, o meglio ancora la sua cache su "File Avenue". Ma
per il momento ho disabilitato questa funzione da iGetter perche` (a
livello tecnico piu` che di utente) sono piu` interessato al problema
teorico di dovere scaricare un file che e` servito da 1 server solo,
senza mirror, e non e` in cache da nessuna parte.
Alex

 appartamento o simile nei dintorni per una settimana?
Temo che per una settimana non si riesca a far sostanzialmente meglio
dei numerosi motel che affollano (ad esempio) El Camino Real a breve
distanza da Stanford (10 minuti in bici, certo dipende da dove devi
andare nel vasto campus;-), a Palo Alto o Menlo Park.  Fra i 40-50
dollari per notte (==35-40 euro, grosso modo;-) ne trovi tanti,
ovviamente non e` che li ho provati tutti ma bene o male sono piu` o
meno equivalenti, a quanto sento.
Alex

 1:40.
Dunque, aridownload dei soliti 16 MB...:
Con curl (una sola connessione): 13:47
Con iGetter (sei connessioni): 1:45
Ovviamente devono esserci anche altri fattori, ma anche alle 4-5 del
mattino ora italiana si conferma un vantaggio mica da poco.
Altre prove:
12 connessioni: 0:48
15 connessioni: 0:42
Questo e` il massimo # di connessioni supportato da iGetter. Devo
ammettere che i 400 KB al secondo raggiunti in quest'ultima prova mi
hanno lasciato basito: _in teoria_ qui a casa ho una banda passante di
10 megabit (almeno, tanto c'e` scritto nelle salate bollette mensili che
mi spedisce l'ISP, e che per fortuna ridirigo dritte dritte a Google;-),
ma non ero mai arrivato neppure vicino ad averli _davvero_...
Alex

 ma non ero mai arrivato neppure vicino ad averli _davvero_...
qui, italietta diroccata, con 10 megabit sono arrivato (1 connessione) a
900kB /s
con 100 megabit non ho mai superato i 5 MB/s (sempre 1 connessione)

 contemporaneamente e vedere che succede
Non vedo come aprire molteplici sessioni simultanee su iGetter, e
neppure scaricare lo _stesso_ file piu` volte simultaneamente. Non credo
che, anche se copiassi quel file di prova 1000 volte con nomi diversi,
operazione "lunga e brodosa" da fare su di un server remoto che mi fa
accedere solo in FTP, potrei comunque aprire mille download simultanei.
Ho fatto invece una prova diversa: ho messo quel file accessibile in FTP
sul Titanium (con airport da 10 megabit) e ho provato a scaricarlo in
vari modi dall'iBook (airport extreme da 100, e l'AP e` un'airport
express pure da 100, quindi il collo di bottiglia e` certamente il wifi
del titanium).  A quest'ora del mattino di sabato sono l'unico in
famiglia ad essere sveglio, quindi nessun altro traffico con la WLAN. Il
meglio che riesco a fare in tanti tentativi con una connessione sola
(provato curl, ftp da linea comando, wget, ecc) e` 350 KB al secondo; da
iGetter, l'optimum e` con 7 connessioni simultanee, con cui arrivo sino
a 410 KB al secondo.
Se persino su di una WLAN senza altro traffico, con banda complessiva
modesta e round-trip basso (secondo ping: round-trip min/avg/max/stddev
= 2.613/4.798/9.527/2.108 ms) l'uso di molteplici connessioni simultanee
porta in modo ripetibile un vantaggio del 15-20%, mi sembra che la pura
e semplice superiorita` tecnica dell'uso di molteplici connessioni
simultanee su TCP possa essere considerata ampiamente dimostrata. Visto
che i vantaggi tecnici, secondo l'analisi che ho gia` postato, sono
legati alla costante principale di caratterizzazione della rete, il
prodotto "round-trip time" per "banda passante" (prodotto che in questo
caso e` assai basso), e alla probabilita` che ogni dato pacchetto di MTU
ottetti "si perda per strada" (pure basso in questo caso, certo non
trascurabile perche` si parla pur sempre di WLAN e non di cavi), questo
del 15-20% puo` essere considerato piu` o meno un limite inferiore; il
vantaggio cresce all'aumento dell'RTT, della banda, della "rumorosita`"
(probabilita` di perdita di ciascun pacchetto), sino al limite delle
"long fat pipes" per le quali siamo tutti d'accordo che bisognerebbe
proprio cambiare il protocollo TCP, e (non potendo cambiarlo)
"affettare" la banda in parecchie "sottobande" ciascuna con un RTT*BW
non eccessivamente elevato e` _sicuramente_ la soluzione meno peggio.
Per ora mi pare di avere speso gia` abbastanza tempo a sperimentare ed
argomentare. In futuro, quando avro` piu` tempo (deadline della 2a
edizione del Nutshell e` fra un mese), potro` fare piu` esperimenti, ad
esempio con download simultanei sulla WLAN da parte di due diverse
macchine, per vedere se e quanto l'uso di connessioni molteplici da
parte di una di esse possa eventualmente danneggiare l'altra. La mia
previsione per ora e` che non lo faccia: se una macchina da sola con una
sola connessione fa sui 350, due macchine in download simultaneo
dovrebbero fare 170-180 ciascuna, una monoconnessione e una
pluriconnessione sempre 170-180 la prima e 200 circa la seconda. Ma "la
scienza nasce dall'esperienza", quindi, vedremo.
Alex

 meno equivalenti, a quanto sento.
temevo anch'io che per l'appartamento fosse dura. Avremmo preferito
quella soluzione per poterci organizzare e mangiare un po' meglio almeno
per i giorni delle gare e speravamo esistessero soluzioni per gente che
studia/lavora in zona. Ho guardato online e mi par di vedere che le
proposte hotel/motel sono veramente tante e per quel che mi ricordo
degli usa il livello è sempre accettabile. Ti ringrazio comunque delle
info.
Riccardo


 wrote:

Prego, mi spiace non potere essere piu` utile.
Alex

 parte di una di esse possa eventualmente danneggiare l'altra. 
attendiamo con ansia :-)
(ma senza fretta, il nutshell e'  + importante)