淘客熙熙

主题:【原创】我有一个问题 -- 美人他爹

共:💬73 🌺79
全看分页树展 · 主题 跟帖
家园 赞同理性讨论,我同意您基本的意思,但有些补充

1。关于stateful,我觉得这是视角不同。您可能是从web programming的角度去看,比如jsp/asp.net的角度,也是多数TX都关心的是在线客户数,但我做web server的,根本不会管连接是哪个客户的。对我来说只要一次http request完成,连接就被放入池中了。这个是现代web server的基本实现,比如apache web server。所以对我来说,所谓的用户在线状态根本就没有意义。这也是为什么我强调stateless易于优化的原因。考虑stateful调用,如果一个组件是有状态的,则在两次调用间我要保存该组件的状态,这对于服务器是非常麻烦的。基本的实现只有两种,一种是该对象不释放,然后等第二次连接时继续使用。这种方案的缺点很明显,就是时间长了服务器要完蛋。第二种是更通常用的,EJB和COM+都是这种方案,就是对象释放回对象池,状态持久于其它地方(比如内存/数据库),也即surrogate,第二次调用时,再从内存/数据库恢复对象状态。这个不会让服务器时间长了就完蛋,但是效率也不会高,主要就是surrogate对象的reactivate是比较费劲的。如果是完全的无状态对象才是比较理想的。

2。关于HTTP RPC调试的问题。实际上您说的不确切,基本上调试HTTP RPC不会用到Sniffer这么复杂的东西。它的原理很简单,就是一个port forwarder。简单说就是一个本地80端口上的daemon,收到caller传入的参数后,forward到服务器,然后收到服务器response后显示出调试信息后再回传给client。这东西写个简单的,在unix下10分钟的事儿,还用不上Sniffer。各个平台上都有这样的东西。

3。HTTP RPC的回调是可以实现的,您GOOGLE web service callback即可。但是这个实现确实不能说是精彩。但话说回来了,RPC中callback没有一个做的很好的,毛病都很多,您可以列举您熟悉的RPC callback,我都可以以实践经验告诉您它的不足。说白了,callback是RPC方式本身的一个本质缺陷了,倒不是HTTP本身的问题。毕竟隔了个网络不可能象本地调用那样一个function pointer搞定一切。我觉得这个只有下一代远程调用模型出来后才能解决。

4。关于活的最好的网络协议。我本来讨论的基础是各种可以承载HTML内容的网络协议,当时主要列了SMTP/FPT/TELNET/HTTP四种,在这四种中我个人意见是HTTP生命力最强。至于扩展到所有网络协议,那DNS强于HTTP那我倒无意见。

最后发点牢骚。其实我本人是做高性能服务器软件工作的,需要啥就做啥,HTTP、FTP、TELNET/SSH、P2P都实现过。我们这个圈子比较封闭,跟外界交流也不多,很少有TX能够接触到这种工作。我在这个圈子里本来是属于对HTTP没什么好感的人,我的兴趣主要是在多机虚拟化上。偏偏在这里讨论就被挤兑成一个HTTP FANS了。我觉得技术问题向来是不能读书不求甚解的。最怕的是一知半解还不肯承认。碰上自己说不明白的,要么指责别人新兵蛋子让人自己翻书,要么就说这个问题太低级,自己翻书或者GOOGLE。我对我自己不懂的事我从来也不会瞎说,或者说错了承认就是了。比如我对于网络游戏这一块的serverside我就是不熟悉,任何东西,说错了我愿意承认。这很多时候是个态度问题。客观的说,西西河信息技术版宏观视角比较多,谈论IT业界天下大势的,有不少新奇见解。但论微观角度,实际技术水平比其它专业论坛差距较大,这与读书不求甚解的风气恐怕有关,宏观的东西不需要太多技术上的验证,所以容易过关。一旦到微观技术视角,很多东西非黑即白,并不容易混过去,这里开口与不开口差异就大了。当然我想也许这是CCHERE的特色吧,其实这也没有什么不好,比如邓侃先生、太守同学的系列,我也都耐心的看完了,不管同不同意,也很喜欢。我相信多样的才是美丽的,所以也希望西西河IT版越办越好。如果言辞有得罪各位老大的地方请谅。

通宝推:响马,
全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河