Rel*_*lla 3 c c# c++ windows project-planning
那么在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"标签",逐个:视频标签,音频标签,视频标签,音频标签等)和Flash播放它!没有特殊的\异常代码.它快速,易于支持,并且不会使客户需要任何新的\异常.而你在服务器端可以采用那种"TAG"形式的视频\音频数据表示.
所以这就是为什么我只是不想使用WCF - 很难在客户端播放实时视频,对于直播视频服务器没有一般的好处.
当大多数实时数据通过套接字时,为什么要使用WCF进行服务管理.
在2009年下半年和2010年上半年,我进入了WCF,实时视频流,银光和闪存,比较了客户端/服务器创建过程,与一群谨慎有趣的开发人员阅读不同的格式.总的来说,在项目结束时,我们有许多迷你服务器流式传输实时数据,许多不同的客户端接收它.比较我们所做的一切,我们得出的结论几乎就是我在这里提出的.
这就是为什么我不想在最近的项目中使用WCF - 我不想考虑如何提供媒体数据,我想专注于它的过滤\编辑.
问题出现的原因
我们开始在C中使用FFmpeg\OpenCV,使用它们操作数据非常简单...在C ...在Linux上...
但是当我们开始使用.Net绑定(我们现在正在使用Tao.FFmpeg)时,我们发现在大多数情况下我们最终使用C#Marshal进行了很多操作,并且有两个变量用于其C模拟(指针问题)等等.我希望我们不会看到Emgu CV这样的问题,但钢铁让我有点担心......
我认为这是完全合理的.C#在易于开发方面的优势将大大超过不使用C++的任何性能缺陷.
C#通常比C++更具跨平台性.确实,C++是一种跨平台语言,但C++程序用来与系统交互的API之间存在很大差异.C#和.Net/Mono具有更加标准化的套接字层接口.
最后,对于像这样雄心勃勃的项目,将项目变为可用形式是一个比获得最高性能更重要的目标.只有项目完成后,性能才有意义.用C#写,因为这将给你最大的完成几率.然后担心性能.
我不确定为什么人们提出跨平台问题,因为OP已经表明该应用程序将在Windows上运行.
至于实际问题.
这是我会做的吗？是.我们已经做到了.我们现在有大约20,000台机器上运行的ac#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数据传输,但是从未构建过能够使通道饱和的驱动器.这意味着在服务器设置中进行认真的计划和资金.
所有这一切的要点是说在你的情况下语言并不重要.您还有其他更大的争用问题.在这种情况下,请使用可帮助您更快完成项目的语言.
为什么要停留在C#,如果你(可能)想要跨平台,用Python或类似的方式编写它,你会发现脚本语言的网络方面远比C#好(因为这几乎是脚本语言的作用)到目前为止,运行基于Web的服务器).
您会发现开发人员的工作效率比C#大大提高(就像C#比C++具有更高的生产力),并且有很多人知道并希望在这些系统上工作.听起来服务器本身的性能不如网络重要,因此看起来脚本将是您的最佳选择.加上ffmpeg库使用pyffmpeg与python比C#更紧密地集成(大多数情况下).
而且它会更酷,更有趣,而且非常跨平台!