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

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版越办越好。如果言辞有得罪各位老大的地方请谅。