在C＃.Net中创建它是否可以，或者我不会把时间浪费在它可以提供给开发人员的简单承诺上并转到C \ C ++？
在我的情况下用C＃编写服务器应用程序是否合理？
Offtop - 为什么不是WCF
警告：它在这里变得主观。
当您拥有每个服务会话的数据交换量相对较小的大公司时，WCF很感激。
当你有视频，LIVE视频时，一切都变得复杂。大量数据，大量用户同时从您的服务流入和流出。
尝试通过http绑定进行实时视频流传输 - 而不是尝试与其他人一起使用，而不是为什么我不喜欢使用WCF进行实时流式传输的想法 - 它很慢，因为实时流媒体信息不需要这么多，毕竟你有没有在WCF上看到过直播视频流媒体应用？不 - 你没有 - 你可能已经看过+ - Silverlight + IIS对的实时视频，我不喜欢它，因为它只适用于Silverlight \ WindowsMediaPlayer视频流解决方案，而我想要更多。
我喜欢拥有覆盖UI的跨平台客户端。我不喜欢（这是我个人的意见 - 所以它是主观的）Silverlight + IIS + WCF组。那么我该怎么办 - 就像FLV和Flash这样古老而简单的格式作为后端客户端进行套接字，流式传输 - 在某些部分开发更简单，在网络上进行实时视频的保守方式比从MS获得的更加保守。今天。
我喜欢Flash FLV直播，因为您只需打开套接字并开始向其发送实时FLV视频数据（针对每个用户FLV标头而不是FLV“TAG”，逐个：视频标签，音频标签，视频标签，音频标签等）和Flash播放它！没有特殊的\异常代码。它快速，易于支持，并且不会使客户需要任何新的\异常。而你在服务器端可以使用那种“TAG”形式的视频\音频数据表示。
所以这就是为什么我只是不想使用WCF - 很难在客户端播放实时视频，对于直播视频服务器没有任何普遍的好处。
当大多数实时数据通过套接字时，为什么要使用WCF进行服务管理呢。
在2009年下半年和2010年上半年，我进入了WCF，实时视频流，银光和闪存，比较客户端/服务器创建过程，与一群谨慎有趣的开发人员阅读不同的格式。总的来说，在项目结束时，我们有许多迷你服务器流式传输实时数据，许多不同的客户端接收它。比较我们所做的一切，我们得出的结论几乎就是我在这里给你的。
这就是为什么我不想在最近的项目中使用WCF - 我不想考虑如何提供媒体数据，我想专注于它的过滤\编辑。
问题出现的原因
我们开始在C中使用FFmpeg \ OpenCV，使用它们操作数据非常简单...在C ...在Linux上...
但是当我们开始使用.Net绑定（我们现在正在使用Tao.FFmpeg）时，我们发现在大多数情况下我们最终使用C＃Marshal进行了很多操作，并为其C模拟设置了2个变量（问题）指针）等等。我希望我们不会看到Emgu CV这样的问题，但钢铁让我有点害怕......
答案 0 :(得分：7)
我认为这是完全合理的。 C＃在易于开发方面的优势将大大超过不使用C ++的任何性能缺陷。
C＃通常比C ++更具跨平台性。确实，C ++是一种跨平台语言，但C ++程序用来与系统交互的API之间存在很大差异。 C＃和.Net / Mono具有更加标准化的套接字层接口。
最后，对于这样雄心勃勃的项目，将项目变为可用形式比获得最高性能更为重要。只有项目完成后，性能才有意义。用C＃写，因为这将给你最大的完成几率。然后担心表现。
答案 1 :(得分：5)
我不确定为什么人们提出跨平台问题，因为OP已经表明应用程序将在Windows上运行。
关于实际问题。
这是我会做的吗？是。我们已经做到了。我们现在有大约20,000台机器上运行的c＃app通过tcp进行有效通信。我们没有使用WCF，但我们确实决定使用REST的RESTful样式服务进行数据传输。
我们最大的问题就是调整应用程序，以便一次通过网络传输“正确”的数据量。该网络用于数据收集和存储。它平均每天收集大约200GB的数据..
<强>更新
我想澄清一下上面的应用程序。上述安装的20,000台机器是客户端（XP，Vista，7,2003服务器和2008服务器）。混合中只有一个数据收集点服务器。当连接到网络时，客户端每45秒一次将数据发布到服务器。大约97％的机器以这种方式保持连接，其余的每周连接几次。
这适用于每天处理大约3700万个请求的服务器。
现在，可以肯定的是，每个请求相对较小，每个请求大约5KB到6KB。但是，剪切请求数表明C＃应用程序可以处理这些连接，这是OP问题的重要部分。
因为OP的文件很大（视频），所以真正的问题只是数据传输。这将受到硬盘驱动器速度以及网络速度和延迟的阻碍。这些问题与您使用的语言无关，并且将根据可用带宽限制每台服务器的连接数。
解决这个问题，让我们将其限制为一台服务器。如果您的视频速率为400kb / s，然后连接到互联网的25MB，则该盒子实际上只能处理大约62个同时连接。这比我们的应用程序正在做的连接数量低得多，因为它是一个舍入错误。
假设完美的网络条件（不存在），将互联网连接高达100MB（这可能很昂贵）意味着同时连接增加4倍到240;还是完全可以控制的。
然而，网络只是等式的一个方面。服务器上的驱动器速度非常重要。您最好拥有一个能够持续提供大量数据的良好磁盘阵列。我知道驱动器要求3GB数据传输，但是从未构建过能够使通道饱和的驱动器。这意味着在服务器设置中进行认真的计划和资金。
所有这一切的要点是说在你的情况下语言并不重要。您还有其他更大的争用问题。在这种情况下，请使用可帮助您更快完成项目的语言。
答案 2 :(得分：5)
为什么要停留在C＃，如果你（可能）想要跨平台，用Python或类似的方式编写它，你会发现脚本语言的网络方面要比C＃好得多（因为这几乎就是脚本编写的角色）现在，语言运行，运行基于Web的服务器。）
您会发现开发人员的工作效率比C＃大大提高（正如C＃比C ++具有更高的生产力），并且有很多人知道并希望在这些系统上工作。听起来服务器本身的性能不如网络重要，因此看起来脚本将是您的最佳选择。加上ffmpeg库使用pyffmpeg与python比C＃更紧密地集成（很好，主要是）。
它会更酷，更有趣，而且非常跨平台！
答案 3 :(得分：2)
如果您想要C＃以及跨平台能力，您的开发将必须以Mono平台（或其他跨平台.NET运行时，如果您可以找到它）为目标。您可能不得不放弃VisualStudio，也许还有一些特定于Microsoft的库和工具，但您仍然可以在多个平台上使用C＃。只需确保您启动多平台构建并在此过程中测试 EARLY ，否则以后会改变它。
答案 4 :(得分：1)
如果应用程序的目标只在Windows平台上运行，我完全肯定用C＃编写这个应用程序。像这样的许多应用程序现在都可以运行，我们甚至都不知道。
如果要在多个平台上运行目标，则应首先封装非Windows平台可为您的应用程序带来的所有问题。
如果在这种情况下，C＃能够完成C ++的所有操作，为什么还要用C ++编写？我会使用C ++对硬件级别的东西进行编程，比如机器人或其他东西。要编写服务器应用程序，C＃将非常适合您想要的，它是为这些东西设计的。
C＃是跨平台的，您只需要合适的工具就可以在特定平台上运行。