Zitat von Maella

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.

Zitat von pawcio

Save Upload Queue Waiting Time (SUQWT) by Moonlight: save each upload queue client's wait time when it exits the upload queue and restore it the next time said client comes back in the queue