I need to limit process’s download and upload speed.
WFP or NDIS Drivers , which one is the best to do this?
I’m trying to do this with wfp , I plan to statistic process download traffic in FWPS_LAYER_INBOUND_TRANSPORT_V4/6.
and statistic upload traffic in FWPS_LAYER_OUTBOUND_TRANSPORT_V4/6 .
then I put packed into a queue. and according SETTINGS to determin how long should I delay before reinject the packets.
will it cause troubles if I delay these packets? or I should just discard packets if traffic is to big?
I serached this question on google , but get nothing .
>I need to limit process’s download and upload speed.
You can set the maximum bandwidth for outgoing traffic or enable QoS for a
process by assigning it to a job object. Check out
JOBOBJECT_NET_RATE_CONTROL_INFORMATION for more information. However, from
what it looks like, this does not allow you to limit incoming traffic.
Well, if you simply delay or discard the incoming packets the only thing you will effectively do is just simulating the problem somewhere “en route”.However, the sender is not going to decrease the amounts of data that it sends to a receiver, because the window that the receiver advertises is not going to shrink. Instead, after a timeout for acked packets elapses the sender is going to repeat the transmission and send the packets again in an expectation that everything is going to work just fine this time. In order to make the advertised window shrink you would have to find a way to make the target app’s socket buffer(s) full, effectively simulating the scenario when the receiving target app is clogged and is simply unable to cope with all incoming traffic at a given rate. At this point TCP implementation on the receiving machine will, indeed, have to tell the sender to slow down a bit…
In other words, the whole thing is not as simple as it seems to be at the first glance…
You need to work on your requirements more before you look at solutions. When you say ?limit a processes? download and upload speed? what exactly do you want to limit? The total bandwidth of all network traffic generated by a certain process? What about network traffic generated on behalf of the process by the redirector (SMB file shares) or for AD authentication purposes? Perhaps you only want to limit the ?speed? on socket connections to TCP port 80 (HTTP) and 443 (HTTPS)?
Next you need to define what you mean by speed. Probably aggregate bandwidth is what you want, but think carefully as there are many possible definitions.
Once you know what it is that you want to limit, then you can work on a solution. As Anton mentions, you can slow down the effective rate of data transfer for TCP connections by introducing artificial packet loss. Understand too that this will not reduce the network usage (at least until congestion avoidance kicks in). I would start by looking into the QoS support built into Windows already and how you might need to extend it for your purposes. Also be aware that ECN bits and TCP window size adjustments exist and probably can do what you need but you usually need to disable TCP offload support to implement this in software
From: xxxxx@gmail.commailto:xxxxx Sent: May 28, 2016 6:41 AM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: [ntdev] is it possible to limit PROCESS network traffic with WFP?
I need to limit process’s download and upload speed.
WFP or NDIS Drivers , which one is the best to do this?
I’m trying to do this with wfp , I plan to statistic process download traffic in FWPS_LAYER_INBOUND_TRANSPORT_V4/6. and statistic upload traffic in FWPS_LAYER_OUTBOUND_TRANSPORT_V4/6 . then I put packed into a queue. and according SETTINGS to determin how long should I delay before reinject the packets.
will it cause troubles if I delay these packets? or I should just discard packets if traffic is to big?
I serached this question on google , but get nothing .
At this point, the whole thing starts looking funny (at least to me). Let’s face it - the OP seems to have chosen the worst platform for experimentation that one may possibly imagine…