让我花一分钟来解释我面临的挑战的背景。 我公司在美国和亚洲设有办事处。 用户在大型CAD文件上工作。 美国的办公室有存储所有文件的NAS（networking连接存储）。 美国用户打开文件没有困难，但亚洲用户需要等待很长时间。 有时最多需要30分钟才能打开文件。 这影响他们的生产力。 这个问题是由networking延迟（300毫秒）造成的。 亚洲有近300名用户。
以下是一些探索的选项。
我也接受其他想法。 不过，我想得到您的意见和build议的软件，实时locking文件和同步数据。 如果有人已经实施或使用这种软件，请提出利弊。
你已经有了主要的select：
当处理更大的数据文件时，后者一直给我们带来最好的结果，另外还可以更好地控制我们的数据，并改善当地工作人员在家工作的可能性。
Citrix的ICA协议已经被certificate可以很好地处理相对较高的延迟/低带宽链路，并为用户提供可接受的用户体验。
较新的虚拟桌面解决scheme在提供video加速以及CAD中可能需要的东西方面甚至更好。
你正在描述公司RIVERBED发明的原因 –
“这个问题是由networking延迟（300毫秒）造成的”
做一些研究 – 你有什么被称为“长胖networking”。
我们始终看到这一点 – 即使纽约和旧金山之间有“1Gbps Cogent连接”。
用户永远不会超过每秒8Mbps，每个TCP连接（与Windows 2008 R2，2003年甚至更低）。
你们应该得到一些Riverbed的，并做到这一点…他们是每个网站12万美元，但这个networking是什么价值给你？
由于时差，您可能能够避免您所关心的文件冲突。 DFS绝对不是以这种方式进行合作的。 但是，您可以通过设置命名空间的方式将用户指向他/她的本地站点。 这样他们会一直打开文件靠近他们。 一旦他们closures文件，DFS将复制到其他网站。 如果发生冲突（不同站点的两个用户对同一个文件进行了更改），最后保存的文件将优先，宽松的文件将被置于“冲突”和“已删除”文件夹下，这样工作不会完全丢失。
对我来说，这比集中文件要好得多，而且要靠networking可用性，广域网优化设备等来实现。这些应该用来补充DFS解决scheme。
这就是说，DFS复制需要Windows服务器两端。 因此，美国的NAS需要由Windows服务器进行DFS复制，以便在亚洲的Windows中进行复制。
看你的post似乎延迟是问题。
你确定你的两个网站之间的networking吞吐量根本不涉及？ 它有多好？ 如果真的延迟是唯一的罪魁祸首，我会尝试使用另一种协议比CIFS（我认为这是你使用，因为你考虑的DFS）。 CIFS是一个非常健谈的协议，它创build了很多来回通信，这使得在高延迟networking上使用它变得很痛苦。 你可以考虑使用像NFS这样的东西吗？
合适的ECM灯可帮助您更有效地共享这些文件。 看看Alfresco（开源和免费社区版本或支付企业），它支持许多协议，locking和文件传输/复制。
300ms是您networking的正常延迟还是造成了一些瓶颈？ 如果这是由于瓶颈造成的，而且您无法进行链路升级，则链路上的某些QoS将帮助您确定stream量的优先级。
关于您发布的选项：
1：是强制性的。 除了caching看QoS之外。
2：RDP在高延迟networking上通常也不好。
3：如果你可以把数据放在云上……但是确保你不会因为亚洲用户更加幸福而使我们的用户感到不快
4：如果您在站点之间坚持CIFS，还是一个选项。