WFP stream layer UPLOAD speed limit

My code inspect in stream layer, block the send/recv package and use FwpsStreamInjectAsync to inject.

The thirty user-mode application send data too fast to stream layer incoming so many data, which code can not process so many data as quickly.

How to slow down the send speed?

I try block data in outbound ippacket , leading send windows size to zero, but the data is not coming this outbound ippacket layer immdiately after call FwpsStreamInjectAsync( , SEND ,…); .

So many package coming to outbound ippacket layer gathered one-time. If I permit package in classifyfn, the package is transported to outbound ippacket layer immdiately.

What the hell is the WFP stream layer! What the hell is the FwpsStreamInjectAsync!

what symptom are you seeing when you say that the data comes too fast? High CPU usage? Excessive memory usage for queued data?

Applications generally send as fast as they can. Is this TCP data?

@MBond2 said:
what symptom are you seeing when you say that the data comes too fast? High CPU usage? Excessive memory usage for queued data?

Applications generally send as fast as they can. Is this TCP data?

The third-party program calls the send function to send data. After the data is blocked in the Stream layer, the size of the sending window does not change because the data is not sent to the TCPIP layer; and after the data is blocked, the send function of the third-party program returns successfully, so it continues to send The remaining data; because the size of the sending window has not changed, the third-party program uploads files very quickly. In fact, the data is still in the Stream layer.

I think this is a flaw in the WFP framework. In the Stream layer, WFP provides inbound rate limiting methods, but does not provide outbound rate limiting methods.

Wy would output limiting rates be desireable? Senders generally send as fast as they can. if the next lower layer can buffer it does; or blocks; or fails the send? So what does this have to do with data arriving too fast in a recieve path? and if it is the send path, then why won’t blocking the call or failing the send work in the out of resources case?