The best way is entirely subjective.
To me, the best way is, whatever reliably and verifiably gets the file from ServerA to ServerB, using the tools with which I am most familiar / can support most easily.
As such, I would send across the file (in your case, probably with rsync) and an associated hash file (MD5, SHA1, etc), then work it into your ServerA job to do that automatically. Then I would work it into your ServerB job to verify the data file using the hash file and continue the process.
I would likely also want to ensure that ServerB does not start working on a partially-transferred file, so I would probably resort to copying to a 'staging' directory on ServerB, then moving to a 'ready' directory — choosing only to poll or inotify the 'ready' directory.
Once that is in place, your immediate work is done and you can continue with the major milestones of your project and can come back to speeding up the transport later.
The most I might do in the early stages is structure the directories on ServerA, so I can tell what is being generated on ServerA and what is being copied to ServerB; probably with a 'pending' directory to which ServerA writes, a 'copying' directory to which ServerA moves the finished file and from which the hashing/rsync processes pick up the file, and an 'archive' directory to which ServerA moves the file when it is done copying to ServerB. That way I can get a rough idea of the latency/queue-length by checking the number of files in the 'copying' folder.
If you do find that you have to improve transfer times, you will probably find that optimising your network stack will be the best way to do so. Fatter pipes between the servers will be in order (e.g. upgrading 100Mb/s to 1Gb/s or even 10Gb/s). You might be tempted to try bonding multiple network interfaces but, if you do, make sure that your bonding algorithm is not picking the same interface every time based on source and destination IP addresses (or some other criteria that will not change — even source-IP+port to destination-IP+port will not offer increased throughput unless you can open multiple simultaneous connections from different source ports and parallelise the copy process).
If you still find the transport to be a prohibitive bottleneck, look to eliminate that in the upgrade path. Try re-factoring so that the jobs on ServerA and ServerB can both eventually be performed by the newer, beefier ServerC. If it is that important to management that these files are processed quickly, it will be an easy-enough sell come project review time.