给所有想学习网络编程的人

Question

我真诚地推荐大家学习一下DCOM,Corba,J2ee,.net,XML,soap技术，而不是浪费时间在网络编程上。须知我们从事网络编程是因为我们需要开发网关，代理等纯粹的网络服务程序（可以认为没有办法选择），而大多数的应用不必用这样的技术，上面的分布式运算技术可以很好地解决几乎一切问题，包括异步消息发送，分布运算，聊天，语音internet传输的等问题。软件的灵魂是重用而不是自己去做别人已经做过的东西，浪费在所谓底层API,Socket,和一些算法上的时间不值得，技术总是在变，如果追求这些东西，永远都没有办法领先.就好像茴字的那些写法一样，知道了也没有什么用处。我的真诚希望能打动一些固执的人（可能是优秀的天才）谢谢：）

Answer 1

我都说了不赞同学习socket编程，怎么还有这么人问Socket阿，难道这东西这么有吸引力？，我不是推荐学习所有我列出的那些东西，而是希望选学，特别是希望大家看看Corba技术和soap技术。有没有人能说出用Socket的理由？特别是不用那些新技术的人

Answer 2

呵呵、、、我就是不会网络编程，但我已经学会了用DCOM的分布式技术，并且用它做了一个挺好的项目。哎呀～！还有好多东东要学呀，Corba、XML、SOAP。。路漫漫其修远兮，吾将上下而求索～！！！！！！！！！

Answer 3

to ljwlover(天涯浪子) 
:)

Answer 4

To ljwlover(天涯浪子）
  我在写一个分布式的系统 用的是DCOM 可以的话想向你请教一下，不知可否？
q106506571

Answer 5

to mul(孤独->自由的代价)
详细的需求需要知道

Answer 6

to ahao(天·狼·星星)
不知你有何高见？愿闻其祥

Answer 7

up一下，又看到有很多人谈论socket相关问题，我认为有必要up一下了

Answer 8

浪费了我的108块啊
我昨天刚买了 windows 网络编程痛阿

Answer 9

高层的东西要学，底层的东西也要学，看各人的学习习惯，何必强分呢？
难道学Socket的就不能学DCOM,Corba,J2ee,.net,XML,soap了？反之亦然.再说Socket学起来哪里有那么麻烦，一个月足以。学好了对高层的理解只
会更加深刻。

Answer 10

我是做游戏的，用SOCKET之外的还不知道什么好呢？

Answer 11

to  luou(大协作)
在win32上 使用DirectPlay for game

Answer 12

Socket和你说的网络编程各有应用领域，替换不了的

Answer 13

的确，底层的东西不要钻的太深，不过话又说回来，有些人就是要钻牛角尖，编什么网络监视器、扫描器，Prober，在实际应用项目中没什么用。
可是，象XML，SOAP这样的新技术和标准出来的速度实在是太快了，了解和掌握这些东西也不比钻牛角尖轻松多少啊。我在93年用DOS和汇编几乎无往不利，到现在都成了废渣，不知道再过4年，我们学的东西又有多少用处

Answer 14

to  pcman1990(pcman) 
除了像我这样做网关什么的，通常分布式开发不需要直接用socket
而分布式开发，通常被称为网络开发。网关之类的开发，我们叫网络系统级开发

Answer 15

这么多网络高手，谁告诉我怎么编一个代理程序？
请寄例程至：[email protected]
或参与讨论
http://www.csdn.net/expert/topic/637/637550.xml?temp=.3370935

Answer 16

您觉得操作系统由没有必要开发，微软公司已经开发过了，您是否知道中国DVD行业的市，由于自己没有开发有自主产权的芯片，DVD论坛就是不肯让步，芯片国外已经制造了。对低层不了解你如何去超越别人，别人开发过了可以使你少走弯路。
我终于知道为什么中国的基础工业不如别人，别人都做过了。
想出名去当CEO，干吗做程序员。

Answer 17

我是做网络视频传输的软件开发的，这么讲求性能和实时性的东西我连MFC都不能用，不用socket你教我用什么？？用你说那些怎么做啊？大哥，你对网络编程的定义也太狭义了吧？

Answer 18

我对网络编程的一些建议完成端口的优点是可以充分发挥多处理器的优点，在单处理器上使用效果并非很好，因此在单处理器，Windows窗体程序中使用异步消息驱动应该是最好的选择。多处理器时用完成端口，如果不嫌麻烦，单处理器可以用重叠模型。强烈反对使用阻塞方式，同非阻塞相比，阻塞方式效率很低，Select方式的效率我的测试表明很低。另外还是事件模型，如果程序没有消息循环，用事件模型是个好的选择，但是如果存在消息循环，用事件模型就不合适！
MFC的CSocket是一个简单低效的东西相信所有做服务器程序的人都不会采用！CAsyncSocket效率要好些，但是封装十分差，我看不如用API自己写一个类，相比下TServerSocket的效率和封装都很好，但是没有源码，不能移植到VC上。他的效率很高，如果打算做一个高负荷的程序TServerSocket是最好的选择，不过如果选择和这个类，也就选择了Borland C++.TTCPServer很象CSocket，效率不是很好。我不推荐用。TPowerSocket的性能是最差的，而且BUG奇多，强烈反对使用。Indy组件的稳定性不错。但是效率一般，特别是阻塞方式效率较差。VBSocket控件不是一个能用的选择，适用范围很有限。因此我不相信有人会在C++环境下使用这个OCX控件

Answer 19

完成端口的优点是可以充分发挥多处理器的优点，在单处理器上使用效果并非很好，因此在单处理器，Windows窗体程序中使用异步消息驱动应该是最好的选择。多处理器时用完成端口，如果不嫌麻烦，单处理器可以用重叠模型。强烈反对使用阻塞方式，同非阻塞相比，阻塞方式效率很低，Select方式的效率我的测试表明很低。另外还是事件模型，如果程序没有消息循环，用事件模型是个好的选择，但是如果存在消息循环，用事件模型就不合适！
MFC的CSocket是一个简单低效的东西相信所有做服务器程序的人都不会采用！CAsyncSocket效率要好些，但是封装十分差，我看不如用API自己写一个类，相比下TServerSocket的效率和封装都很好，但是没有源码，不能移植到VC上。他的效率很高，如果打算做一个高负荷的程序TServerSocket是最好的选择，不过如果选择和这个类，也就选择了Borland C++.TTCPServer很象CSocket，效率不是很好。我不推荐用。TPowerSocket的性能是最差的，而且BUG奇多，强烈反对使用。Indy组件的稳定性不错。但是效率一般，特别是阻塞方式效率较差。VBSocket控件不是一个能用的选择，适用范围很有限。因此我不相信有人会在C++环境下使用这个OCX控件

Answer 20

又被打击,才准备学socket呀！怎么办？