Seeding ratio fissa

feature_request

#1

Continua la discussione da Lista Caratteristiche Primarie della prima release Tsunami:

Un sistema molto facile, sarebbe impostare Tsunami per gestire automaticamente i files condivisi e cancellarli solo dopo aver condiviso almeno il doppio del file scaricato.
La coda di seeding quindi non avrebbe più’ bisogno di gestione manuale. I files condivisi verrebbero cancellati dal Tsunami in automatico.
In questo modo per la legge dei grandi numeri i files comunque avrebbe la sicurezza di essere stati distribuiti, e la sicurezza che tutti i peer e utenti di Adu siano altruisti. Ne deriverebbe in questo modo che all’aumentare degli utenti AdunanzA il network continuerebbe a crescere e aumentare la banda disponibile.


Tsunami, nuova interfaccia stile metro
#2

E invece considerare i peer completi presenti nel file più che la quantità distribuita?


#3

E anche quella una possibilità ma c’è una differenza profonda. I peer completi potrebbero aver scaricato da altre fonti (torrent ma altri client /metodi).
Con la tua proposta ti assicuri che la distribuzione sia avvenuta (ma non garantisci che la gente cancelli i file).
Con la mia proposta ti assicuri che i peer non siano dei free rider cattivi e non pesino sugli altri ma condividano attivamente.


#4

Il problema è che la quantità distribuita non garantisce che il file sia completo.
E metterle tutte e 2 è possibile?


#5

vero anche quello, non hai la garanzia ma hai la probabilità.
Comunque in ogni casa reputo piu’ importante che i peer adunanza siano rinomati per la loro generosità e contributo al network piuttosto che i files siano completi senza ombra di dubbio.
E’ sicuramente fattibile anche avere tutti e due i controlli come avevamo in parte su emule ma dobbiamo dare priorità alle modifiche finchè nessuno si offre per aiutarci nello sviluppo.


#6

Sul discorso peer e ratio è giusto mettere delle regole tuttavia un utente medio su alcuni file,per una serie di considerazioni,potrebbe essere indotto a rimuoverli dalla condivisione non appena terminati(ammesso che sia utile!).
Torrent sembra agevolare la raccolta di log da parte delle compagnie anti p2p in modo estremamente semplice.
Vorrei leggere le considerazioni di utenti più esperti in merito,senza entrare nell’ anonimizzare con vpn,seedbox etc etc
Siete d’accordo su questo difetto,a mio avviso dei protocolli Torrent,oppure il controllo fattibile sui client è lo stesso di quanto lo era su Emule Adunanza ?


#7

E’ proprio quello il punto. Se si mette in conto un tot di giga di “cache” o spazio per usare tsunami, poi non c’è piu’ bisogno di gestire nulla. Lo fa tsunami e impedisce cattivi comportamenti. In piu’ gli altri sapranno che se sei un utente Tsunami sei un figo e altruista. :meme_fuck_yeah_clean:
@Roma33 apriti una discussione apposita o biforca questa per parlare di quell’argomento diverso.


#8

Cancellati dalla coda, cioè rimossi dalla condivisione, o cancellati fisicamente dal disco?
Immagino sia la prima, ma meglio chiarire :smile:
In questo caso, si dovrebbe prevedere anche la possibilità di reinserili in coda manualmente se dovesse servire.

E se, ad esempio, voglio sharare un file piuttosto raro? Sarebbe utile poter cambiare questa impostazione in modo da tenerlo in seeding anche quando viene superato il ratio predefinito.


#9

Certo si potrebbe usare una spunta per condividerlo a dispetto del normale ciclo di morte del seeding.
Intendevo cancellaro solo dalla coda di seeding e muoverlo in una cartella apposita.


#10

Hai ragione Hammon non è la sede adatta ma l’ intervento potrebbe diventare una sorta di feature,ovvero non sarebbe possibile un sistema anti tracciabilità ? E’ fattibile o ci escluderebbe dai vari tracker ? All’utente generico penso che la lettura degli ip dei seed peer e riceventi sia completamente inutile ! Probabilmente anche senza quello se vogliono analizzare lo scambio di file lo fanno comunque ma con il sistema attuale chiunque,senza grandi conoscenze tecniche, sarebbe in grado di raccogliere dati e prove su eventuali violazioni di legge !


Offuscamento
#11

C’è un problema.
Sto notando che alcuni file raggiungerebbero a stento la ratio di 2 ad esempio.
E’ come se la connettività fosse carente e non fossero condivisi o cercati a sufficienza.


#12

Questo l’ho notato anch’io scaricando e poi upando file relativamente vecchi (di qualche anno fa), ma in questo caso credo sia fisiologico, una cosa vecchia è meno ricercata.


#13

Si potrebbe parlare di selezione naturale, che è quello che mancava ad emule.
Troppi files inutili che toglievano banda agli effettivamente ricercati, rallentanto la rete. Pero’ la conettività mi preoccupa.


#14

Spiega meglio, non ti seguo. In che senso hai notato problemi di connettività?


#15

Faccio una considerazione, forse controcorrente (e forse un po’ OT, perdonatemi)

Secondo me bisogna appunto valorizzare i file rari, sono attualmente ciò che manca al torrent e che invece c’è su adunanza: più un file è raro più alzerei la priorità che venga scaricato. Già sul mulo ci si mette tanto a scaricare un bel classico, ma è naturale perché lo hanno in pochi. Con torrent è praticamente impossibile.

Un file meno ricercato non vuol dire meno importante. Se un file è molto diffuso, sarà facile scaricarlo comunque, la maggiorparte degli utenti scarica e condivide file diffusi. Faccio un esempio: uno vuole scaricare l’ultimo film dei Vanzina, lo trova facilmente perché in molti lo hanno; uno cerca “i sette samurai” non riesce a scaricarlo perché tutti stanno condividendo l’ultimo “vacanze di natale” e nessuno ha banda per il film di kurosawa.

Ora non dico che bisogna diventare paladini della cultura, ma valorizzare i file rari di qualità secondo me è un’ottima strada da seguire, anche per ingrandire la community.

Non capisco: i file inutili per definizione non li scarica nessuno. Se ci sono e vengono tenuti in codivisione probabilmente hanno un perché di esistere. Altrimenti, anche se in condivisione, ma nessuno li ricerca, non fanno alcuna differenza, mi sbaglio?

Spero di essermi fatto capire… Forse sono il solo a pensarla così, ma sarebbe bello se la community adunanza continuasse a differenziarsi per la qualità dei contenuti condivisi, oltre che per le prestazioni del software.


#16

Su che basi fai capire al client che un file è raro e quindi deve tererlo in share di più?
La cosa più oggettiva sarebbe basare il tutto sul numero di seed e peer, ma non è “esatto” come metodo. Quando viene pubblicata una release il numero di peer è ovviamente basso, ma capita in alcuni casi che il releaser debba rilasciarne una seconda versione a causa di problemi. In questo caso ovviamente si toglie dalla condivisione il file “non buono” il prima possibile, ma se gli imponi un ratio di 10 (ad esempio, è un numero buttato lì) perchè il client pensa sia raro, e il releaser lo rimuove prima di raggiungelo, paradossalmente finiremo con il penalizzare i releaser…

Secondo me non puoi vincolare troppo gli utenti. Va bene impostare un ratio fisso per tutti i file, ma il resto spetta alla sensibilità degli utenti stessi.


#17

Se il file è “raro” vuol dire che al 99% della gente non interessa = spreco di banda.

Non dico di non tenerlo in condivisione, anzi, ma non vedo perchè dare priorità a file “rari”.


#18

@JDM il tuo discorso non fa una grinza, bisogna lasciare che sia l’utente a scegliere la ratio a seconda del valore che dà a un determinato file.

@Dax Capisco anche il tuo di discorso, ma non vedo perché se una cosa interessa al 99% della gente, il rimanente 1% debba rimanere tagliato fuori. Bisogna aiutare le minoranze no? In ogni settore.


#19

Io non sto dicendo di tagliare fuori nessuno:

sto dicendo di non dare priorità ai file rari, appunto perchè rari e poco ricercati!

Certo, tenendo il file in condivisione, mica dandogli anche il “sussidio di disoccupazione” tanto per fare un esempio.
Altrimenti avvantaggi 1 utente (potenziale) a scapito di altri 99 (certi).


#20

E allora deve averla un files con 100 fonti complete?
Dovrebbe essere il client a gestire la priorità dei files in base alle fonti complete disponibili.
Ti ricordo che nel mulo c’era la priorità Adurelease (Release nel mulo normale) che aveva come limite 8 fonti complete,
e poi diventava in automatico Alta quando le superava.