In the past few weeks a few tickets were raised regarding slow transfers between geographically distant end points. These transfers are using the UDP-based FileCatalyst protocol to take advantage of the acceleration offered for long hauls. Remarkably enough, they ran into issues from the same root cause.

One client has several remote operations transferring from LA to India. One of the upload tasks was performing far below other remote operations. The client uploading the files is in a tightly locked down environment. According to the client, the proper ports were opened for both UDP and TCP. Other locations in the same region had no issues with UDP transfers. Not being able to access the remote site directly, I used the remote applet to diagnose the possible cause. Write speeds tested fine and data was indeed getting across (ie. not blocked entirely). I changed the protocol to TCP in an attempt to determine if there was an intrusion detection, firewall or anti-virus issue. Using TCP, the transfer was allowed to move through the DMZ without being throttled. This let the client know their security was throttling his transfers: a pre-configured rule mistakenly identified the UDP traffic as file sharing. With the problem identified, the client was able to adjust their configuration and allow the FileCatalyst traffic.

A second trouble ticket presented itself as a more unusual case. The scenario was point to point upload and download over a long haul. This client has been using our software for a couple of years and had been putting off upgrading to newer releases. They had, however, migrated the FileCatalyst Server from a Windows platform to a Linux platform and then back to Windows. After moving to the new Windows machine, they were experiencing terrible speeds with upload performance but downloads were unaffected. We first tested write speed to verify that the new hardware was not at fault. Next we opened a SSH session to test a basic upload directly to the Server and found that it was transferring at expected speeds. UDP was being shaped or otherwise throttled. We changed the sending protocol to TCP and assigned additional sending threads to boost outgoing speed. This indeed allowed them to transfer at expected speeds. In this case, acceleration via multi-threaded TCP performed well enough that further configuration of their security measures was not required.

The takeaway is simply this: when you encounter slow transfers using UDP, switch the protocol to TCP and see how it performs. It may be that a security measure needs to be configured to allow full-speed UDP traffic. Alternatively (or while waiting for the updated configuration), multi-threaded TCP may do the trick for fast file transfer.