远程管理和数据捕获：WCF、SQL Sync、SyncFramework、BITS 还是其他？
我们在各个客户站点上有几千台 Windows XP 客户端计算机，它们都运行一些交互式软件，这些软件用于收集匿名使用数据。客户端计算机使用一些旧的、旧的、旧的客户端服务器软件，将数据上传到基于互联网的服务器，将配置信息推送回它们，并可以要求客户端执行一些任务，例如重新启动。
本质上，我们具有以下功能（在伪 C#/IDL 中）：
interface IClientToServer
{
void LogUsage(clientMachineName, anonymousUserID, Pair[] usageData, startTime, endTime);
void LogError(clientMachineName, errorMessage);
void LogUptime(clientMachineName, bootTime);
DateTime SyncClock(clientMachineName, timezone);
}
interface IServerToClient
{
void UpdateSettings(Pair[] settings);
Bitmap GetScreenshot();
void Reboot();
string Execute(cmdLine);
}
..但是此代码已达到其生命周期（脆弱，由于缺乏技能而无法维护）。
我们即将启动一个全新的项目，使用现代工具、SDK 和框架重新设计该软件。
我们有一些功能要求，它们是：
- 由于可用的工程资源，基于.NET的环境。
- 防火墙友好 - 我们只能通过 HTTP/80 从客户端站点与基于互联网的服务器“通话”，并且互联网访问不稳定，客户端带宽相对较差。 VPN 不受我们客户群的欢迎。
我们对这里可以利用的技术数量之多感到不知所措：.NET Remoting、.NET Web Services、WCF、Sync Framework、SQL Pub-Sub、SQL Sync、BITS 等。
我们可以深入了解哪些技术选择最适合这里的设计。
有什么“自然”的契合吗？
We have a few thousand Windows XP client machines on various customer sites that are all running some interactive software which is instrumented to collect anonymous usage data. The client machines use some old, old, old client-server software that uploads the data to an internet-based server, pushes configuration info back down to them and can ask the clients to do some tasks like reboot.
In essence, we have the following features (in pseudo C#/IDL):
interface IClientToServer
{
void LogUsage(clientMachineName, anonymousUserID, Pair[] usageData, startTime, endTime);
void LogError(clientMachineName, errorMessage);
void LogUptime(clientMachineName, bootTime);
DateTime SyncClock(clientMachineName, timezone);
}
interface IServerToClient
{
void UpdateSettings(Pair[] settings);
Bitmap GetScreenshot();
void Reboot();
string Execute(cmdLine);
}
..but this code has reached its end of life (fragile, unmaintainable due to lack of skills).
We are about to embark on a greenfields, start-with-a-clean-slate project to rework this software using modern tools, SDKs and frameworks.
We have some functional requirements, which are:
- .NET based environment due to available engineering resources.
- Firewall-friendly - we can only talk 'out' from client sites to our internet-based server over HTTP/80 and internet access is flaky with relatively poor client bandwidth. VPNs are unpopular with our customer base.
We are rather overwhelmed by the sheer number of technologies that we could leverage here: .NET Remoting, .NET Web Services, WCF, Sync Framework, SQL Pub-Sub, SQL Sync, BITS, etc.
We could use some insight into what technology choices would best suit the design here.
Is there any 'natural' fit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会选择 WCF。您可以轻松地将其配置为使用基本 HTTP。需要时，您可以更改任一端的绑定，以便可以使用不同的协议进行通信。这使得它变得灵活。您还可以选择以适合您需求的方式托管 WCF 服务（IIS、NT 服务或您可以想到的任何其他 .NET 进程）。
此外，WCF 很容易设置，.NET 为您提供了通信所需的所有工具，因此您不必做尽可能少的管道工作。
I'd go with WCF. You could easily configure this to use basic HTTP. When needed you can change the bindings at either end, so you can use a different protocol for communication. This makes it flexible. Also you can choose to host the WCF service in a way that suites your needs (IIS, NT Service, or any other .NET process you can come up with).
Also, WCF is easily setup and .NET gives you all the tools you need for communication, so you don't have to do as little plumbing as possible.