就我而言，用 C# 编写服务器应用程序是否合理？

Question

• 我希望它能够在 Windows 服务器上运行。
• 它将是一个云类型服务器 - 它将由运行在世界各地不同机器上的模块\部分组成，使用http\tcp + upnp相互连接
• 每台机器上将有控制\监控\观察模块提供性能统计数据
• 该网络将处理大量视频\音频生活流\广播数据
• 它将使用 FFMPEG 进行重新编码，使用 OpenGL、OpenCV 等进行过滤（顺便说一句，.NET 包装器存在并工作）
• 它不会使用任何 WCF 或 IIS
• 我想在 2-4 名开发人员（聪明的学生）团队中开发它。

那么，在 C# .Net 中创建这个可以吗？或者我不会浪费时间在它可以为开发人员提供的轻松承诺上，并转向 C\C++？

那么就我而言，用 C# 编写服务器应用程序是否合理？

---

Offtop - 为什么不 WCF

警告：这里变得主观。

当您的大公司每一次服务会话的数据交换相对较少时，WCF 会非常有用。

当你有视频、现场视频时，一切都会变得复杂。大量数据、大量用户同时从您的服务中流入和流出。

尝试通过http绑定进行实时视频流 - 比尝试其他人你会明白为什么我不喜欢使用WCF进行实时流媒体的想法 - 它很慢，实时流信息不需要way2much，毕竟你曾经有过见过 WCF 上的实时视频流应用程序吗？不 - 你还没有 - 可能你已经看过 +- Silverlight + IIS 对上的实时视频，我不喜欢它，因为它仅适用于 Silverlight\WindowsMediaPlayer 视频流解决方案，而我想要的不止于此。

我喜欢拥有具有 UI 的跨平台客户端。而且我不喜欢（这都是我个人的意见 - 所以它是主观的）Silverlight+IIS+WCF 组。那么我该怎么办 - 正确使用套接字，以 FLV 和 Flash 等古老而简单的格式进行流作为后端客户端 - 某些部分的开发更简单，通过网络进行实时视频的方式比从 MS 获得的方式更保守今天。

我喜欢 Flash FLV 实时流媒体，因为您只需打开套接字并开始向其发送实时 FLV 视频数据（对于每个用户 FLV 标头和 FLV“标签”，一一：视频标签、音频标签、视频标签、音频标签等） Flash 就可以播放它！没有特殊\不寻常的代码。它快速、易于支持，并且不会使客户需要任何新的\不寻常的东西。您在服务器端可以充分利用视频\音频数据表示的“TAG”形式。

简而言之，这就是为什么我不想使用 WCF - 很难在客户端播放实时视频，对实时视频服务器没有一般好处。

当大多数实时数据通过套接字传输时，为什么还要费心使用 WCF 进行服务管理。

在 2009 年下半年和 2010 年上半年，我开始接触 WCF、实时视频流、silverlight 和 flash，比较客户端/服务器创建过程，与一群谨慎有趣的开发人员一起阅读不同的格式。一般来说，在项目结束时，我们有很多迷你服务器流式传输实时数据，并且有很多不同的客户端接收数据。比较我们所做的一切，我们得出的结论与我在这里向您介绍的结论很接近。

这就是为什么我不想在最近的项目中使用 WCF - 我不想考虑如何传递媒体数据，我想专注于它的过滤\编辑。

---

为什么出现这个问题

我们开始在 C 中使用 FFmpeg\OpenCV，并且使用它们来操作数据非常简单...在 C 中...在 Linux 上...

但是当我们开始使用 .Net 绑定时（我们现在正在使用Tao.FFmpeg）我们发现，在大多数情况下，我们最终会经常使用C# Marshal，并且有2个变量用于其C模拟（指针问题）等等。我希望我们不会在 Emgu CV 上看到这样的问题，但钢铁这让我有点害怕......

Answer 1

我认为这是完全合理的。 C# 在易于开发方面的优势将大大超过不使用 C++ 带来的任何性能缺陷。

C# 通常比 C++ 更具跨平台性。诚然，C++ 是一种跨平台语言，但 C++ 程序用于与系统交互的 API 之间存在很大差异。 C# 和 .Net/Mono 对套接字层有更加标准化的接口。

最后，对于像这样雄心勃勃的项目，将项目变成可用的形式是比获得尽可能高的性能更重要的目标。仅当项目完成时，性能才重要。用 C# 编写它，因为这会给你最大的完成机会。然后担心性能。

Answer 2

我不太清楚为什么人们提出跨平台问题，因为 OP 明确表示该应用程序将在 Windows 上运行。

至于实际问题。

1. 您能否用 C# 构建一个通过 tcp/http 进行通信且不必在 IIS 中运行的服务器应用程序。 ->是的。
2. 您能否用 C# 构建一个高性能且可扩展的服务器应用程序 ->是的。
3. 你能和学生一起这样做吗->或许。取决于学生...;)但这与使用的语言无关。

这是我会做的事吗？是的。我们已经做到了。目前，我们的 ac# 应用程序在大约 20,000 台机器上运行，这些机器通过 TCP 进行有效通信。我们没有使用 WCF，但我们确实决定使用基于 http 的 RESTful 风格服务来进行数据传输。

我们最大的问题是简单地调整应用程序以一次通过线路传输“正确”的数据量。该网络用于数据收集和存储。平均每天收集约 200GB 的数据。

更新
我想澄清一下上述应用程序。上述安装中的 20,000 台计算机是客户端（XP、Vista、7、2003 Server 和 2008 Server）。其中只有一台数据收集点服务器。当连接到网络时，客户端每 45 秒向服务器发送一次数据。大约 97% 的机器以这种方式保持连接，其余的机器每周连接几次。

这相当于服务器每天处理大约 3700 万个请求。

现在，可以肯定的是，每个请求相对较小，约为 5KB 到 6KB。然而，大量的请求表明 C# 应用程序可以处理这些连接的管理，这是 OP 问题的主要部分。

因为 OP 的文件很大（视频），所以真正的问题只是数据传输。这将更多地受到硬盘速度、网络速度和延迟的阻碍。这些问题与您使用哪种语言无关，并且会根据可用带宽限制每台服务器的连接数量。

为了解决这个问题，我们将其限制为一台服务器作为示例。如果您的视频速率为 400kb/s，并且有 25MB 的互联网连接，那么该设备实际上只能处理大约 62 个同时连接。这远远低于我们应用程序正在执行的连接数，因此存在舍入误差。

假设完美的网络条件（这并不存在），将互联网连接增加到 100MB（这可能很昂贵）意味着同时连接数增加 4 倍，达到 240 个；仍然完全可以管理。

然而，网络只是等式的一方面。服务器上的驱动速度非常重要。您最好拥有一个能够连续传输这么多数据的良好磁盘阵列。我知道驱动器声称可以传输 3GB 数据，但从未制造过能够使通道饱和的驱动器。这意味着在服务器设置方面需要认真规划和投入资金。

所有这一切的目的是说，在你的情况下，语言一点也不重要。您还有其他更大的争用问题。在这种情况下，请选择能够帮助您更快完成项目的语言。

Answer 3

为什么要停在 C# 上，如果你（可能）想要跨平台，用 Python 或类似的语言编写，你会发现脚本语言的网络方面比 C# 好得多（因为这几乎是脚本语言的角色）到现在，运行基于网络的服务器）。

您会发现开发人员的工作效率比 C# 提高了很多（就像 C# 比 C++ 的工作效率更高一样），并且有很多人了解并希望在这些系统上工作。听起来服务器本身的性能不如网络重要，因此脚本似乎是您的最佳选择。另外，与 C# 相比，ffmpeg 库使用 pyffmpeg 与 python 的集成更加紧密（嗯，主要是）。

而且它会更酷、更有趣，而且非常跨平台！

Answer 4

如果您想要 C# 以及跨平台能力，您的开发将必须针对 Mono 平台（或其他跨平台 .NET 运行时，如果您能找到的话）。您可能不得不放弃 VisualStudio，也许还有一些 Microsoft 特定的库和工具，但您仍然可以在多个平台上使用 C#。只需确保在此过程中尽早开始多平台构建和测试，否则稍后更改将是地狱。

Answer 5

如果应用程序的目标是仅在 Windows 平台上运行，我完全确定用 C# 编写此应用程序。许多类似的应用程序现在可以运行，但我们甚至不知道。

如果目标是在多个平台上运行，您应该首先封装非 Windows 平台可能给您的应用程序带来的所有问题。

如果在这种情况下，C# 能够完成 C++ 所做的一切，为什么必须用 C++ 编写它呢？我会使用 C++ 对硬件级的东西进行编程，比如机器人或其他东西。要编写服务器应用程序，C# 非常适合您的需求，它就是为这些事情而设计的。

而且C#是跨平台的，你只需要合适的工具就可以让它在特定的平台上运行。