Le opzioni esclusive: Xtreme I e Xtreme IIXtreme IUna coda per ogni file (Code multiple) : se abilitata, imposterà una coda per ognuno dei nostri file condivisi; ciò comporta che non avrebbe senso dare priorità alta ad un file raro. La priorità alta ai file rari la si da quando si vuol favorire la loro diffusione privilegiandoli rispetto agli altri nostri file
nella nostra coda (appunto con la priorità e quindi un punteggio maggiore al client che ce li richiede); se le code sono una per ogni file, il discorso "priorità" non ha più senso.
Annotazione a margine (di Pier4r): Se si lascia la priorità automatica, allora effettivamente ogni file avrà la stessa priorità e la coda sarà equa. Se invece si cambia manualmente la priorità, l'effetto si fa sentire.
Apri più Slot se necessario (raccomandato) : in base al limite upload che abbiamo assegnato ad ogni singolo slot (
opzioni - connessione - Velocità slot UP), spuntando questa voce la Xtreme aprirà un nuovo slot qualora la velocità di qualche client sia superiore al 20% di quanto riesce ad ottenere (ad esempio il massimo che può ricevere da noi è 5 Kb/s a causa della saturazione della sua banda download o per altri motivi, e noi gli stiamo inviando di più). E' raccomandato attivare questa funzione.
NAFC - Controllo Totale dei limiti di UL/DL : il NAFC non è altro che un alternativa all'Upload Dinamico presente in altre versioni di eMule. Non è equivalente in quanto, a differenza dell'upload dinamico, il NAFC gestisce anche la velocità di download in modo dinamico; ma la vera caratteristica è che non si limita a gestire solo l'upload ed il download di eMule, ma anche delle altre applicazioni che in quel momento utilizzano la nostra banda, permettendo così di ottimizzare il tutto settando i valori di upload e download migliori per garantire costantemente il massimo rendimento della nostra linea.
Spiegazione dettagliata del NAFC data da Maella Spoiler NAFC (Network adapter Feedback Control)explanation by Maella:
Zitat:
Introduction
All applications that need to regulate their upload bandwidth face the same problems. When you ask the operating system (OS) to send data to a remote client, three different things could happen:
- The sending could be proceed immediately
- The sending could be delayed by the OS (e.g. remote client not ready, limit of the capacity of the network already reached)
- The sending could be never proceed by the OS (e.g. connection with the remote client is lost)
Another problem is that a part of the traffic on the network is generated by the protocol itself. So typically when data are received from a remote client, the OS must send some acknowledge (ACK) packets to the remote side to validate the transfer. These ACK will increase the overall traffic as well. The protocol creates an overhead that an application can not fully control.
And finally, others applications can generate traffic for their own purposes (e.g. ftp, browser).
In summary: when an application attempts to regulate its traffic, it knows what it's trying to send, but it doesn't know exactly when it is sent and what it is sent.
Ideal Solution
In the case of eMule, the ideal solution would be to know in real time the current level of the traffic though the modem (e.g. K56, ADSL, etc..). So if an application was award of it, it would be piece of cake to regulate the bandwidth. Keep in mind that the goal is to use all the time 100% of the capacity of the modem. Nothing more, nothing less!
Unfortunately, there is no easy way to retrieve this information from the modem.
Current solutions
There are different approach to solve the above problem. Here it a list with some of them:
1. Under use the bandwidth to insure having enough rooms for the protocol overhead (e.g. the official eMule).
Disadvantage:
-all bandwidth is not used
2. Try to send periodically packets (ping) with the purpose of measuring the reaction time of the modem. So if the reaction time gets too high, it could indicate a beginning of saturation of the modem (e.g. ZZ UploadSpeedSense).
Disadvantage:
-add overhead to the traffic for the measure
-limited reaction time > 1s
-medium accuracy
3. Try to measure the reaction time of the remote clients. (e.g. SUC).
Advantage:
-no overhead
Disadvantage:
-limited reaction time >1s
-medium accuracy
-depends on the capacity of both the local and remote modems.
4. Measure the traffic at the network adapter level (Ethernet card) and not at the modem level. If all the traffic is only exchanged with the modem, then the network adapter will have a 1 to 1 image the modem's traffic => NAFC
Advantage:
-no overhead
-reaction time very fast <100 ms
-very accurate
Disadvantage:
-not available with all OS (e.g. win95)
-might require administrator right (could be change somewhere in settings)
-measure all the traffic sent or received by the local computer on the network (e.g. traffic with the modem + traffic with other computers on the local network)
5. Use the Layered Service Provider of windows....
Summary
The NAFC is certainly the best solution, but only if the network adapter is only used to exchange data with the modem.
Traduzione in italiano (autore della traduzione Starway) SpoilerTutte le applicazioni che necessitano di regolare la banda in upload hanno gli stessi problemi.
Quando viene richiesto al Sistema Operativo (SO) di spedire dei dati ad un client remoto, possono accadere tre differenti cose:
1. la spedizione viene eseguita immediatamente
2. la spedizione viene ritardata dal SO (es. il client remoto non è pronto, il limite della capacità del network è stato raggiunto)
3. la spedizione non può essere processata dal SO (es. la connessione con il client remoto è andata persa).
Un altro problema è che una parte del traffico del network è generato dal protocollo stesso.
Così è tipico che quando i dati vengono ricevuti da un client remoto, il SO debba far ritornare qualche pacchetto di riconoscimento (ACK) per convalidare il trasferimento.
Questo ACK aumenterà anche il traffico totale .
Il protocollo crea un overhead che un'applicazione non può pienamente controllare.
In fine, altre applicazioni possono generare traffico per i propri scopi (es. ftp, browser).
Riassumendo: quando una applicazione cerca di regolare il suo traffico, essa conosce cosa sta per essere spedito, ma non sa esattamente quando sarà spedito e se sarà spedito.
Soluzione Ideale
Nel caso di eMule, la soluzione ideale è quella di conoscere in tempo reale l'attuale livello di traffico attraverso il modem (es. K56, ADSL, ecc...).
Se l'applicazione potesse conoscere il livello di traffico, di conseguenza sarebbe più facile regolare la banda.
Ricordati che lo scopo è quello di usare sempre il 100% della capacità del modem.
Niente di più, niente di meno!
Sfortunatamente, questa non è una via facile per ricavare queste informazioni dal modem.
Soluzioni correnti
Ci sono approcci differenti per risolvere il problema. Qui sono elencati alcuni di essi:
1. Sottosfruttamento della banda per assicurarsi di avere abbastanza spazio per l'overhead del protocollo (es. eMule ufficiale).
Svantaggi:
- non viene sfruttata tutta la banda
2. Spedire periodicamente un pacchetto (ping) con lo scopo di misurare il tempo di reazione del modem. In questo modo, se il tempo di reazione è troppo alto, questo sta ad indicare l'inizio della saturazione del modem (es. ZZ UploadSpeedSense)
Svantaggi:
- aggiunge overhead al traffico
- tempo limite di reazione > 1s
- media accuratezza
3. Misurare il tempo di reazione dei clients remoti (es. SUC)
Vantaggi:
- nessun overhead
Svantaggi:
- tempo limite di reazione > 1s
- media accuratezza
- dipende dalla capacità di entrambi i modem.
4. Misurare il livello di traffico direttamente sull'adattatore di rete (scheda Ethernet) e non il livello del modem. Se tutto il traffico viene scambiato solamente con il modem, il network (LAN) è una immagine 1:1 del traffico del modem => NAFC
Vantaggi:
- nessun overhead
- tempi di reazione molto veloci <100ms
- molto accurato
Svantaggi:
- non è disponibile per tutti i SO (es. Win 95)
- sono richiesti privilegi di amministratore (devono essere cambiati alcuni settaggi)
- misura tutto il traffico spedito o ricevuto dal computer locale nella LAN (es. traffico con il modem + traffico con tutti gli altri computer collegati in rete)
5. Uso del Service Provider di Livello
PS. Il NAFC è la soluzione migliore, ma solo se l'adattatore di rete è usato esclusivamente per scambiare dati col modem.
Usa Quantità basata sul rapporto 1:3 se l'Upload è < 11 : Se attiviamo questa funzione e la velocità di upload è al di sotto degli 11 Kb/s, avremo una limitazione del download SOLO al raggiungimento del rapporto UP/DW di 1:3. Se invece l'opzione è disattivata, e si scende sotto gli 11Kb/s di upload, il download verrà automaticamente limitato anche se il rapporto 1:3 non è stato ancora raggiunto (esempio: limitando l'upload a 10 Kb/s avremo un limite in download di 40 Kb/s). Si consiglia di attivarla.
Buffer di invio : il buffer di invio standard è 8.192 byte e viene utilizzato dal sistema operativo. Quando eMule invia un pacchetto, questo viene inviato al buffer e solo successivamente trasmesso all'esterno. Ma solo il sistema operativo decide quando realmente sarà inviato.
Con un buffer di invio basso, eMule è in grado di tenere sotto controllo l'upload e di tenerlo stabile. Con un buffer alto, eMule lascia un maggiore controllo al sistema operativo, ma spesso si può raggiungere una velocità di slot più alta. (se non si sa bene come impostarlo, meglio lasciare il valore di default)
MTU : Unità massima di trasmissione; indica le dimensioni massime in byte di un pacchetto dati che può essere inviato attraverso un protocollo di comunicazione (fonte
wikipedia). Il valore va impostato in base alla propria linea; per una linea ADSL in PPPoA il valore consigliato è 1500 mentre per linee ADSL2/2+ in PPPoE è 1492. Se non sapete come impostarlo, è preferibile lasciare 1340. (ovviamente dovrete modificare l'MTU anche dalle impostazioni del router, della scheda di rete e dal registro di windows)
Usa doppia dimensione di invio : Ogni pacchetto inviato ha bisogno di un pacchetto di ritorno da parte del client. L'idea di una doppia dimensione di invio è di inviare due pacchetti in una sola volta, in modo che il client che riceverà dovrà inviarci un solo pacchetto in cambio. La versione ufficiale di eMule utilizza questo sistema, però ci sono degli svantaggi, come ad esempio, potrebbe portare ad un aumento dell'overhead.
Conviene attivarla solo se si hanno velocità di upload maggiori di 50 Kb/s o velocità per singolo slot superiori a 6 Kb/s.
Rimuovi i socket che si bloccano troppo spesso : selezionabile solo se abbiamo abilitato l'opzione "
Apri più slot se necessario". Serve ad eliminare automaticamente dalla propria coda di upload quei client che, per loro problemi, si bloccano spesso (ad esempio passano continuamente da 0 Kb/s a 10 Kb/s).
Sempre un solo slot release : viene riservato un unico slot per i file messi in release in modo da evitare la saturazione della banda di upload solo con i file che abbiamo messo in release.
Usa Priorità upload automatica avanzata : se attiviamo questa funzione, la Xtreme gestirà automaticamente tutti i nostri file condivisi
ai quali abbiamo dato priorità automatica in base al numero di fonti presenti nella rete. Questo per favorire l'upload dei file più rari. Nella schermata
File condivisi noteremo che verranno assegnate le priorità
Auto [ - ] -
Auto [ + ] -
Auto [ = ] a seconda della diffusione del file.
Aggiorna Flusso dei dati Medio ogni : questa regolazione agisce sull'aggiornamento del flusso dati (upload, download ed overhead) ogni tot secondi. La scala va da 1 a 20 (consigliato 10). Poichè le velocità non sono mai costanti, se proviamo a mettere 1 sec. (quindi un aggiornamento ogni secondo) noteremo variazioni enormi soprattutto nella velocità di download, il che non ci farà avere le idee chiare. Meglio impostare un aggiornamento medio.
Metodo di scelta chunk : abbiamo 2 possibilità,
Maella o
zz. Il metodo
Maella è quello utilizzato dalla versione ufficiale sino alla 0.47b, mentre invece
zz è un metodo utilizzato nella Mod ZZul (poi introdotto anche nella versione ufficiale). Il metodo
Maella fa in modo che eMule scarichi un segmento
diverso di ogni file per ogni fonte; invece
zz concentrerà il download sul
medesimo chunk per permettere un completamento più rapido, quindi ogni fonte ci darà una parte di quel chunk. La scelta del metodo è soggettiva, ma è consigliabile usare il metodo zz in quanto ormai utilizzato dal client ufficiale.
(ringrazio LorenzoC)Aggiornamento automatico IPFilter.dat : se spuntiamo questa voce, ad ogni avvio la Xtreme cercherà un aggiornamento IP filter all'indirizzo che abbiamo inserito su
Aggiorna dall'URL in
Opzioni-Sicurezza; se non abbiamo inserito nessun URL in quel campo, al riavvio comparirà un messaggio di errore di questo tipo:
Mostra rapporto blocco socket : se lo attiviamo, comparirà una percentuale nella finestra degli upload che rappresenta la percentuale dei socket bloccati.
Ritenta connessioni TCP fallite : selezionando questa opzione, permetteremo alla Xtreme di ritentare una connessione TCP a una fonte dopo che è appena fallita invece che eliminarla direttamente. Si necessiterà di più connessioni, ma si perdono tra il 10% e il 30% di fonti in meno. Consigliata per il download di files rari. (
)
Priorità del Processo : qui non facciamo altro che decidere la priorità che vogliamo assegnare alla Xtreme; in pratica gli assegnamo una quantità più o meno alta delle nostre risorse (cioè della nostra CPU).
Xtreme II
Anti-LeecherQuesta parte è dedicata al filtro anti-leecher. Si può personalizzare la scelta delle caratteristiche da includere nel controllo; si può decidere se bannare o ridurre il punteggio di alcune leecher mod (
nota: ridurre il punteggio significa mantenerle nella vostra coda ma ..... in fondo 
).
DLP v44 è la versione del filtro (è aggiornabile); il tasto
Reload serve per ricaricare la dll del filtro qualora l'avessimo appena aggiornata ad una nuova versione (ad esempio
DLP v45).
Basta scaricare la dll nuova (solitamente
antiLeech.dll.new), metterla nella cartella della Xtreme e premere il tasto Reload (oppure riavviare direttamente la Xtreme).
Per ulteriori informazioni sul DLP vedi
qui.
Mostra in grassetto i download attivi e
Usa font piccoli nella finestra trasferimenti, si commentano da sole.
Mostra linee grafico addizionali : se attivata, mostrerà nei grafici delle statistiche una ulteriore linea
eMule control + data (solo nei grafici di download ed upload) e che corrisponde al valore di velocità (upload o download) + overhead relativo.
Visualizza nome utente funny : capita spesso che gli utenti usino il nick di default (ad esempio
http://emule-project.net); se attiviamo questa funzione, il nick di default di tutti i nostri amici e di tutti i client che abbiamo contattato (SOLO quelli che hanno lasciato il nick di default) saranno cambiati automaticamente in nick simpatici come ad esempio
[FN] EDonkey,
[FN] Cruel Erc, ecc... attingendo da un database di nick.
Questa guida è pubblicata con licenza Creative Commons Attribution 2.5 License 
