Remoting还是Socket？（C/S开发）

Question

目前这个项目是服务器端和客户端需要有大量数据交互的，既要上传也要下载，小弟原来做b/s开发，换了公司开始做c/s开发，所以不甚了解，希望各位高手解释几个问题，谢谢。1.是用流媒体直接播放还是选择将文件传到本地播放，现在倾向于每天定时传数据到客户端，这样不受网络限制。2.用Socket还是Remoting，这个真的没做过，重点是传输速度，成功率，穿越网段能力，安全机制和开发难度，这两种模式哪种好。3.能否推荐两本有比较完整实现的书。因为内裤只有三个，所以只能先送100分了，拜谢。。

Answer 1

个人觉得 Socket 好一些

Answer 2

如果不排除开发难度的问题，也就是说你的团队很有实力的话建议使用Socket，毕竟网络通讯都是基于Socket的，但是往往底层的东西写起来也会很棘手，如果项目周期不长的话建议使用Remoting，.Net2.0中的Remoting微软做了很多工作，效率比1.1提高了不少，一个更重要的原因是微软对Remoting的支持，也就意味着以后你可以随着.Net的升级获得好处。

Answer 3

假如没有扎实的网络编程功底，还是用remoting吧
网络编程可不是web service那样形同儿戏

Answer 4

Remoting , MS recommend it!

Answer 5

Remoting实现起来还是比较容易上手，，
他的远程处理能力，，应该可以应付你的那些需求了，，
remoting搞数据分发还是可以的。。

Answer 6

建议用Remoting，考虑以后的版本基本上还用.net，对于微软开发新东西比较不错的。

Answer 7

如果是实时的流媒体播放，并且自己实现服务器
那么就选择Socket,用Socket你的应用才能完全被你掌控，但是开发的周期比较长。呵呵，传输速率和你支持的流媒体文件的压缩算法有关系，你的算法足够好的话，发送1K的数据能比上别人发送10K的数据。你以前做B/S的，如果没接触过C/S的开发的话估计需要用很长时间才能够完整的客户端应用开发技巧，这个不是说看一两本书就能解决的。我觉得最好找现成的东西，比如说window的流媒体服务器或Real的Helix server，这样就省事儿多了。而且你在这里空谈用何种技术来实现我觉得意义不大，不如有这时间去看看我说的那辆样产品，你包装一下就行了。Remoting是用Socket实现的一种应用技术，无法和Socket相提并论，不是一个层面的东西。

Answer 8

楼上说的不错,Remoting是用Socket实现的一种应用技术,像你传输的流媒体数据,要的是速度.
这样的话,传输的数据量就应该越小越好,如果Remoting技术的话,因为其是基于Socket的,其传递的数据包必增加了许多与其协议有关的数据,虽然单条数据不见得多,但是对于流媒体来说长时间运行其冗余的数据就相当可观了

Answer 9

谢谢楼上的诸位，尤其是storm97(风暴不再)。因为不是实时的，客户端的设计也比较复杂，所以不会采用windows或real的服务器，而是能让客户编辑和播放自己的节目。看来对于我这项目还是用remoting好些，开发时间限制和remoting的封装优势相对快捷些。。thanks all:)

Answer 10

越接近低层你掌控的机会就越多,同样对传输调试和优化都有很大的优势.
了解Socket->封装基于Socket的应用组件(需要经验积累比较困难)->基于组件做业务应用.
当传输层封装好之后的工作就会很轻松.
虽然remoting提供远程方法调用非常方便.但还是建议用Socket(.net的Socket已经封装很好了,使用也不会有太大困难).

Answer 11

Remoting可能在传输数据上比较方便．但限制也不少．用Socket来处理的话，如果封装好了的话，后期开发应该不慢．前期可能要一些时间．楼主根据时间来选择吧．技术方面，偶也认为Socket强过Remoting