RadAsyncUpload and TCP Zero Window

[Richard]

Good afternoon,

I'm currently running Telerik UI for ASP.NET AJAX R3 2023.  I am using the RadAsyncUpload with a AsyncHandler.ashx to copy the file to a RadUploadTemp on a file share.

This has been working perfectly for ages but recently large file updates have been failing e.g. a 2.1 GB file failing at 61%.  I'm being told this is due to a TCP Zero Window issue.

I assumed the chunked upload mechanism mitigates the issues caused by TCP window size restrictions, which can cause slowdowns or failures when uploading very large files in a single request. I am setting the upload ChunkSize value to 4194304.

I have the following settings in web.config:

  <system.web>    
    <httpRuntime maxRequestLength="2097151" executionTimeout="18000"/>
  </system.web>

  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="4294967295"/>
      </requestFiltering>
    </security>
  </system.webServer>

Have you got any ideas as to why it might be failing for larger files, or what I can do to the configuration to prevent the TCP Zero Window error by pausing data transmission until the receiver is ready to accept more data?

Kind regards,

Richard

[Hester]

Hello, 

Your chunk size of 4194304 bytes (approximately 4 MB) is reasonable, but you might want to experiment with smaller chunk sizes, especially if the network is unstable or if the server has a limited ability to process large data chunks. Try reducing the chunk size to 1048576 bytes (1 MB) to see if it improves upload stability. Moreover, I think you should ensure that the timeout settings are sufficient for large uploads. You can try increasing the executionTimeout in your web.config further, though it seems you already have it set quite high (18000 seconds).

[Richard]

Hi Hester,

Many thanks for your reply.

I've tried different chunk sizes (1 MB, 2 MB and 8 MB) but ultimately it gets to the same point where approximately 170 MB has been transferred in 20-30 minutes and the transfer halts.

Increasing the executionTimeout won't help as it's set to 5 hours and we're seeing problems much earlier than that.

Is there anything else I can try, or do you think this problem is being caused by the network?  There are a couple of gateways on the network so it's possible one of those is causing the drop in the TCP connection.

Kind regards,

Richard

[Rumen]

Hi Richard,

Since the RadAsyncUpload implementation hasn't changed and you're seeing issues only with large files after a long transfer duration, it’s very likely that the problem is related to network throughput, file I/O bottlenecks, or resource exhaustion rather than the upload control itself.

Here are several steps and considerations that might help pinpoint and resolve the TCP Zero Window issue:

Isolate the Destination Bottleneck

• Try writing to a local folder instead of the network file share (RadUploadTemp). If the upload succeeds, it strongly suggests that the file share (or its network path) is introducing latency or blocking writes during large uploads.
• Exclude the upload folder from antivirus scanning, especially if you are using real-time protection tools. These can interfere with large or partial files during write operations.

Investigate Network and Gateway Behavior

• Check your gateway configuration: If your setup involves reverse proxies, load balancers, or other intermediaries, verify that they are not imposing timeout or connection limits on long-running uploads.
• Use network tools to capture network traffic during the upload. Look for stalled connections, retransmissions, or signs that a gateway is dropping or throttling the connection.

Tune Server and TCP Parameters

• Monitor server resources (CPU, memory, disk I/O) during the upload. A saturated server can fail to process incoming data fast enough, triggering TCP Zero Window conditions.
• Consider adjusting TCP buffer sizes on both client and server sides. In some environments, increasing the receive window size can delay or prevent the window from closing prematurely.

Try Alternate Network Paths

• If feasible, test the same upload on a different network or subnet. This can help determine whether the issue is specific to the current network segment, gateway, or firewall configuration.

In summary, it looks like the issue is not with RadAsyncUpload itself, but rather with how the network or storage layer handles prolonged, high-volume uploads. Narrowing down whether it is the file share, network devices, or system-level buffers will help resolve it.

Regards,
Rumen
Progress Telerik