在我的例子中，用C#编写服务器应用程序是否合理？

Question

我希望它能在windows服务器上工作。performance

• This
• 将是一种云型服务器-它将由运行在世界各地不同机器上的模块\部件组成，使用http\tcp + upnp连接到彼此的
• ，将在每台机器上控制\监视\观察模块以提供在网上的统计数据，它将处理大量的视频\音频生命流\广播数据
  • ，它将使用FFMPEG重新编码和OpenGL，OpenCV等用于过滤(.NET包装器存在和工作的BTW)
  • 它将不使用任何WCF或IIS
  • ，我想在2-4个开发人员的团队中开发它，聪明的学生。

  。

所以，在C# .Net中创建这个系统可以吗?或者我不会把时间浪费在它可以为开发人员和go C\C++提供方便的承诺上吗？

在我的例子中，用C#编写服务器应用程序是否合理？

Offtop为什么不WCF？

警告:在这里它会变得主观。

WCF是当你有一个大公司与相对较小的数据交换每一次服务。

当你有视频，现场录像，一切都变得复杂起来。大量的数据，大量的用户同时从您的服务中进出。

尝试在http绑定上做实时视频流--而不是和其他人一起尝试--这是为什么我不喜欢用WCF进行实时流的想法--这很慢，因为way2much不需要实时流媒体信息，而且您是否见过WCF上的实时视频流应用程序？不-你没有-可能你看过+-在Silverlight + IIS对上的实况视频，我不喜欢，因为它只是为Silverlight\WindowsMediaPlayer视频流解决方案而我想要的更多。

我喜欢拥有带有reach用户界面的跨平台客户端，我不喜欢(这都是我个人的观点，所以它是主观的) Silverlight+IIS+WCF组。那么，我该做些什么呢?我应该做些什么呢?我应该去套接字，像FLV和Flash这样的旧的简单格式的流作为后端客户端--在某些方面更简单，在网络上做实时视频的方式比今天从MS那里得到的更保守。

我喜欢Flash直播，因为你只需打开套接字并开始向其发送实时FLV视频数据(对于每个用户FLV头和FLV的“标签”，一个接一个:视频标签、音频标签、视频标签、音频标签等)，Flash播放它！没有特殊\不寻常的密码。它速度快，易于支持，不需要任何新的\不寻常的东西。在服务器端，您可以使用这种“标记”形式的视频\音频数据表示。

因此，这就是为什么我只是不想使用WCF -很难从它的客户端获得现场视频播放，没有一般的好处现场视频服务器。

而且，当大多数活数据通过套接字时，为什么要费心使用WCF来进行服务管理。

在2009年下半年和2010年上半年，我进入了WCF、实时视频流、silverlight和flash，比较了客户机/服务器的创建过程，与一群谨慎有趣的开发人员一起阅读了不同的格式。一般来说，在项目结束时，我们有大量的小型服务器、流媒体直播数据和许多不同的客户端接收它。比较我们所做的一切，我们得出了接近一个的结论，我在这里向你们介绍。

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

为什么会出现这个问题

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

但是，当我们开始使用那里的.Net绑定时(我们现在使用的是Tao.FFmpeg)，我们发现在大多数情况下，我们经常使用C# Marshal，并且它的C模拟(指针问题)有两个变量等等。我希望我们不会在Emgu简历上看到这样的问题，但是它让我有点害怕……

Answer 1

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

至于实际的问题。

1. 可以构建一个服务器应用程序，该应用程序通过C#中的tcp/http进行通信，而不必在IIS中运行。->是的。
2. 可以构建一个性能良好的服务器应用程序，可以在C# ->中扩展。
3. 可以与学生一起使用->。取决于学生们..。)但这与所使用的语言无关。

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

我们最大的问题是简单地调整应用程序，以便一次通过有线传输“正确”的数据量。这个网络是用来收集和存储数据的。平均每天收集200 of的数据。

更新

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

这对服务器来说是可行的，每天处理大约3700万个请求。

现在，可以肯定的是，每个请求都相对较小，每个请求大约在5KB到6KB之间。但是，请求的切变数量表明，C#应用程序可以处理这些连接，这是OP问题的更大部分。

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

解决这个问题，让我们把它限制在一个服务器上作为一个例子。如果你有一个400 62 /s的视频速率和一个25 62的连接到互联网，那么这个盒子在物理上只能处理大约62个同时连接。这远远低于我们的应用程序所做的连接数量，这是一个舍入错误。

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

然而，网络仅仅是方程的一个侧面。服务器上的速度非常重要。您最好有一个好的磁盘阵列，能够持续地传送那么多的数据。我知道驱动器声称3GB的数据传输，但是一个可以饱和通道的驱动器从来没有建立过。这意味着在服务器设置中需要认真的计划和资金。

所有这一切的意义在于，语言在你的处境中一点也不重要。您还有其他更大的争用问题。在这种情况下，使用能够帮助您更快完成项目的语言。

Answer 2

我觉得这完全合理。C#在易于开发方面的好处将大大超过不使用C++的任何性能缺陷。

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

最后，对于像这样雄心勃勃的项目，将项目变成可用的形式比获得尽可能高的性能要重要得多。只有当项目完成时，性能才重要。用C#编写它，因为这将给您最大的完成概率。那就担心表演吧。

Answer 3

为什么要停在C#上，如果你(可能)想要跨平台，用Python或类似的语言编写它，你会发现脚本语言的网络方面要比C#好得多(因为现在脚本语言在运行基于web的服务器时所扮演的角色差不多就是这个角色)。

您会发现，与C#相比，开发人员的生产力有了很大的提高(就像C#比C++有更好的生产力一样)，并且有很多人知道并希望在这些系统上工作。听起来服务器本身的性能不如网络那么重要，所以脚本似乎是你最好的选择。另外，与使用pyffmpeg的python相比，ffmpeg库与python集成得更紧密(主要是C# )。

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