我有一個問題，需要我計算可用的最大上載和下載，然後將我的程序的使用限制在一定百分比內。但是，我想不出找到最大值的好方法。以編程方式確定最大傳輸速率
目前，我唯一可以提出的解決方案是在客戶端和服務器之間傳輸幾兆字節，然後測量傳輸的方式。但是，這種解決方案非常不理想，因爲擁有100,000個客戶端可能會導致服務器帶寬使用量增加太多（已經太高）。
有沒有人有任何解決方案來解決這個問題？
請注意，我最感興趣的是數據的傳輸限制，直到它離開ISP的網絡;我認爲這很可能會導致其他程序通信降級的瓶頸發生。如果我錯了，請糾正我。
編輯：經過進一步調查，我不認爲這是可能的;準確測量離開ISP網絡時的最大傳輸速率涉及太多變量。儘管如此，如果有人提出了一個準確的解決方案，那麼這個問題就會解決。
我看到的唯一答案是：
一些問題複雜化的問題：
由於客戶端可以運行其它任務，並且主機（發送機）將運行不同的任務，傳輸速率會有所不同。
我投了一個數據塊來計時，發送另一個數據並計時。累積這些持續時間，並在塊的數量上取平均值。這允許動態計時，這將比任何預先計算的計時更準確。
如果你可以限制代碼到Windows Vista或更高版本（不太可能，但誰知道？），你可以使用SetPerTcpConnectionEStats和GetPerTcpConnectionEStats隨着TCP_ESTATS_BANDWIDTH_RW_v0讓Windows估計帶寬的連接，後來檢索估計。然後，根據這個估算，你可以節制你使用的帶寬。
那麼會發生什麼情況是，您將像現在這樣開始運行應用程序，收集一段時間的統計數據，然後根據您在初始時間段內測量的數據進行限制。
這樣做的好處是避免發送額外的數據只有收集帶寬信息 - 它只是收集你發送的數據的統計數據。它有一個缺點（我懷疑它幾乎是不可避免的），它仍然使用接近全帶寬的東西，直到估計出可用的帶寬爲止（並且，如上所述，這是在Windows Vista中添加的，因此它甚至不太接近普遍可用）。
不幸的是，我們必須支持Windows XP。 :( – 2010-05-10 18:59:37
如果問題是原始帶寬，那麼反饋機制可以在這裏工作。 當您開始會話時，服務器會以最快的速度告訴客戶端它將發送數據。客戶端可以以最高速度收到數據。如果接收數據的速率低於數據發送速率（可以使用此處的閾值，比如低於90％），則客戶端通知服務器節流數據速率並再次啓動該過程。這將作爲基本的QoS機制。
如果問題是連接具有較高的延遲和/或抖動，請嘗試以較小的包（實際的IP/TCP包）發送信息。通常系統會嘗試使用最大數據包大小，但互聯網上的數據包碎片可能會延遲流量。如果這仍然不能改善延遲，那麼你可以使用UDP而不是TCP。但這不能確保數據傳輸。
如果在連接的兩端都有Windows設備，則可以使用後臺智能傳輸服務（BITS）將信息和警報移出整個帶寬問題。 （幾乎）始終安裝的組件在http://msdn.microsoft.com/en-us/library/aa362708(VS.85).aspx中描述。
您不說是否需要帶寬友好性或僅僅是成本問題，因此這可能不合適。
一種選擇是在客戶端和服務器之間實現類似uTorrent's UDP transport protocol的操作，以延遲等待時間。當其他進程開始使用帶寬時，僅測量原始吞吐量也無濟於事，從而減少了免費的帶寬量。
你在編寫代碼的操作系統是什麼？您可能至少可以檢索特定界面的理論最大值，但執行此操作的方法會因操作系統而異。 – 2010-05-07 15:36:40
Windows。我對接口的最大值不感興趣，我對可以通過客戶端的ISP傳輸的最大值感興趣;如果允許，我們的程序將使用它提供的所有內容，這會降低其他應用程序的性能。從可用性的角度來看，讓用戶選擇自己的限制是不可接受的。 – 2010-05-07 15:44:51
除了在傳輸過程中對實際傳輸速率進行抽樣以外，不要以爲您有更多的選擇。如果你不想粉碎你的服務器，你可以考慮使用現有的服務之一來衡量它 - 比如speakeasy.net。有人必須爲你提供一個API。 – AlG 2010-05-07 15:53:48