Funzioni extra > NAFC
A cura di
starway
NAFC (Network Adapter Feedback Control)
Introduzione
|
|
Tutte 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:
- la spedizione viene eseguita immediatamente
- la spedizione viene ritardata dal SO (es. il client remoto non è pronto,
il limite della capacità del network è stato raggiunto)
- 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. |
