Tinyfool的开发日记(blog)

刚才用Google搜索我自己的名字“郝培强”的时候，遇到了一个提示[Why so slow/tainted?]。


Technorati Tags: Google, Python

eMule协议专题

• eMule协议简要分析[一]
• eMule协议简要分析[二]
• eMule协议简要分析[三]

客户端服务器TCP连接

每个客户端用TCP连接一个服务器。服务器给客户端分配一个ID，用于在会话中唯一标识这个客户端（高ID总是跟据它的ID地址来分配）。电骡客户端需要一个服务器连接才能操作。客户端不能连接到多个服务器，没有用户干预情况下客户端不能动态改变服务器。

连接建立

客户端创建连接的时候，可能会同时连接到多个服务器，仅仅使用成功的登陆流程，其他的连接直接放弃。
这里有两种连接建立的情况：

1. 高ID??服务器分配一个高ID给客户端。
2. 低ID??服务器分配一个低ID给客户端。
3. 拒绝??服务器拒绝客户端的连接。
   

当然不用说，还有服务器死机和无法连接的情况。

高ID登陆流程

上图描述了高ID登录的消息交换流程。在这种情况下，客户端创建一个到服务器的连接，传送他的登录消息给服务器。服务器用另外的TCP连接去 连接客户端，进行一次客户端到客户端的握手，用来确认客户端有能力接受其他的电骡客户端的连接。在完成了客户端到客户端握手之后，服务器关闭第二个连接， 并发给客户端他的ID作为客户端服务器握手的终结。 你可能注意到上图中的eMule info是灰色的。这是因为这个消息属于eMule协议的扩展。

低ID登陆流程

上图描述了产生低ID连接的流程。在这种情况下，服务器无法连接到客户端（客户端到客户端的握手），所以给客户端分配了一个低ID。通常服务器消息会包括 这样的一个警告“Warning [server details] - You have a lowid. Please review your network config and/or your settings.”。不管高ID还是低ID，握手都是由id change消息结束的，这个消息给客户端在下面的跟服务器的会话提供了一个客户端ID。

登录被拒绝流程

上图描述了登录被拒绝的流程。当客户端是低ID或者服务器已经到达了硬件能力极限，服务器都有可能拒绝登录。服务器消息里面会包含拒绝理由的简单描述。

连接开始的信息交换

客户端和服务器成功建立连接之后会交换一些设置消息。这些消息的用途是更新两端的状态信息。客户端首先把它的共享文件列表发送给服务器，然后它要求更新它 的服务器列表。服务器发送它的状态和版本，然后发送它知道的eMule服务器列表，并提供一些自识别的细节。最后客户端询问源（可以用来下载它的下载文件 列表中的文件的客户端），服务器返回一系列消息，知道所有的源列表都被客户端得到为止。

文件搜索

文件搜索是由用户触发的。这个操作是简单的，一个搜索请求发给服务器后，服务器会返回一个搜索结果。当结果有很多的时候，搜索结果消息会被压缩。然后，用 户选择下载其中的一个或多个文件，客户端会请求所选文件的源，服务器返回一个所请求文件的源的列表。一个可选的服务器状态信息可能会在发现源的消息之前发 送给客户端。这个状态信息包含了服务器支持的当前用户和文件数量。注意，这是一个UDP补充消息，用来增强客户端定位源的能力的。确定这些源是新的以后， eMule客户端进行连接，并把他们加到他的源列表内。根据客户端收到源先后顺序连接这些源。没有任何优先级机制来决定先连接哪个源。但是当一个源同时被 下载列表中的多个文件需要的时候，有一个补充机制可以解决问题（注意，eMule只允许两个客户端间建立一个传输连接）。这个选择算法寄予用户指定的文件 优先级，如果没有优先级就根据字母顺序。

回调机制

回调机制是设计用来克服低ID客户端无法接受连入连接的问题的，这样他们也可以跟其他的客户端共享文件。这个机制很简单：如果客户端A和B都连接到同一个 eMule服务器，A需要的一个文件在B上，而B是一个低ID，A可以给服务器发送一个回调请求，请求服务器要求B反过来连接A。服务器已经跟B有了一个 TCp连接，发送给B回调请求消息，把A的IP和端口提供给B。B就可以连接到A，把文件发送给A，而不需要服务器更多的参与。很明显，只有高ID客户端 可以要求低ID客户端回调（低ID没有能力接受连入的连接）（这就是为什么高ID可以跟任何的源连接，而低ID只能跟高ID连接的原因）。这也是允许两个低ID客户端通过服务器交换文件的方法，服务器作为中转。但是因为这样对服务器负担太重，目前大部分的服务器已经不在支持中转了。

前些日子有朋友约了篇稿子“独立开发商，出路何在？”，一时托大就答应了，写起来才发现这个题目真是难写，很难把握，只能敷衍了一篇东西了事。后经编辑修改刊登出来了，这里把原稿发一下，好坏都是自己写的，文责自负。也算是对曾经深爱的Borland的一种纪念，不管怎么说Tc、Bc ，Delphi，Bcb都曾经是我的最爱。

---

独立开发工具厂商的生存

作为最大的独立软件开发工具厂商，borland曾经有自己的辉煌。他们的产品Turbo c、Turbo Pascal都是在Dos时代最流行的开发工具，拥有无数的拥趸。然而在Pc平台逐步地图形化的过程中，Borland犯了几次足以致命的错误，Borland C++ 4.0有严重的质量缺陷大大的损害了Borland的声誉。最终Borland C++ 5.0推出之时Windows下面开发的首选早已经成为了Visual C++，最终Borland不得不停止此条产品线的开发。

这样的失败是偶然的,也是必然的。Dos时代是微软和独立开发工具厂商的蜜月，Dos平台上第三方开发平台越多，越有利于Dos平台的推广。那个时代微软的财力和能力没有办法包打天下。Windows时代，微软开始努力让Borland边缘化，而.Net时代，Borland就几乎变得无足轻重了。

那么独立开发工具厂商如何生存呢？

1、努力建立自有的平台

微软有双重身份，作为操作系统厂商微软有责任义务给第三方开发工具厂商支持，第三方开发工具越多微软平台的推广越容易；然而，同时他也是一家全球最大的开发工具厂商之一，当独立开发工具厂商跟他在开发工具方面有正面竞争的时候，他也会利用他独占的操作系统的信息来打败对方。Borland Bc++ 5.0中的OLE实现没有达到用户的要求，主要原因之一就是微软刻意的对Borland等其他厂商隐瞒了一些核心技术。

在别人的操作系统上面进行竞争，就像跟一个既是运动员也是裁判的家伙赛跑一样，很难获胜。独立开发工具厂商的出路在于自己的平台的建设。一个平台可以是一个操作系统，一个虚拟机，是一个类库。从这个角度看,Sun就是一个成功的例子，从Java2开始，Sun从一家独立开发工具厂商转型为一家平台提供商，有了自己的地盘才能让别人听我们的。Borland有Linux下的Kylix，Win32/DotNet下的Delphi和C++ Builder，C# Builder，CBX，有Java平台下的JBuilder，而这三个平台，Borland都不是领导厂商，这就是Borland一切问题的根源。这些遍布各个平台，不同语言的产品，没有形成一种合力，所以Borland的地位十分尴尬。

其实Borland比微软更需要一个类似DotNet这样的虚拟机平台，微软全线产品都是基于Windows平台的，所以没有平台整合的要求，只有组件库整合的要求。但是DotNet技术上虽然可以跨平台，但是它是微软严格控制的，所以只有一个第三方的实现Mono是真正跨平台的。这正是Borland的机会，微软的优势是天时，微软掌握了中低端的主流操作系统平台，劣势在于微软不可能涉及其他操作系统的开发工具市场，与微软对阵需要Borland扩展不同平台的业务，避免把主要的盈利预期放在单一平台；Sun的优势是地利，Sun掌握了最流行的虚拟机，劣势是Java虚拟机根Java语言集合太紧密，Sun很难开展其他语言的业务，与Sun对阵需要Borland强化自己在不同语言上面的优势；天时地利已被他人占据，从Borland的历史和积累看，Borland应求人和，开发自己的虚拟机平台，对上同时支持Windows和其他的平台，甚至可以支持Java和DotNet的虚拟机平台，对下学习DotNet对多语言的资源进行整合推出相对统一的组件库。

这条道路是最难走的，需要巨大和长期的投入，但是一旦成功，收获也是最大的，是为上策。

2、开源也是一种选择

建立自己的平台是非常困难的事儿，需要非常雄厚的技术积累和巨大的推广能力，所以上策只适合像Borland那样比较大的独立软件开发厂商。规模比较小的公司可以考虑如何利用开源获得更大的竞争力。这里包含两个层面：

立足开源产品

立足开源产品是目前开发工具市场已经是群雄四起的情况下，小公司迅速成长的一条道路。一方面可以节约平台建立的资源耗费，另一方面可以避免自己被平台厂商控制。另外专注于某些特定领域的开发工具厂商也可以利用开源产品，使自己更专注自己的核心技术。典型的例子就是著名的嵌入操作系统厂商风河系统公司，选择Eclipse作为自己的开发工具的IDE，放弃了自己开发的IDE。这样有利于风河更专注于自己的操作系统和嵌入产品，而不是把精力放在IDE的美化和优化。

让产品开源

IBM花了4000万美元开发Eclipse，然后却把Eclipse捐献给Eclipse基金会，然后把他们开发的基于Eclipse的各种插件打包销售，这是一个很有意思的现象。把Eclipse开源是为了让Eclipse成为一个广泛使用的IDE平台，而这个平台兴旺发达了以后，基于这个平台的业务也自然而然会蒸蒸日上。

这条路是没有能力建立自己平台的独立开发工具厂商的选择，投入较少，收获自然也较少，是为中策。

3、蓝海战略

任何我们一眼就可以看到的市场都是过度拥挤的，竞争都很激烈，也就是所谓令企业陷入血腥竞争的"红海"，要想躲避残酷的竞争，而是要开创"蓝海"市场，即蕴含庞大需求的新市场空间。

蓝海战略就是要求独立开发工具厂商发现还没有被满足的开发者的需求，成为先行者。Visual Basic的成功就是一个典型的例子，Visual Basic是第一个获得商业成功的快速应用开发工具，它允许程序员在一个所见即所得的图形界面中设计程序。这一产品满足了程序员在Windows平台上进行快速图形化应用开发的需求，所以获得了最大的成功。

蓝海战略最大的问题是如何找到还没有被满足的用户需求。就目前软件行业发展来看，有两个趋势，一个是大公司为了应对越来越复杂的软件需求而组建的越来越大的项目组，一个是小公司为了灵活应变快速反应而形成的超小规模开发团队。尤其是小团队，他们往往不需要一些昂贵的开发辅助工具，他们需要廉价的，轻量级的，可以方便组合的开发工具。这个需求并没有得到比较好的满足，应该是一种趋势。

蓝海战略，投入较少，但是风险较大，很有可能你发现的用户需求用户根本不需要，所以是为下策。

长期支持的问题

一个开发工具开发工具单个版本的生命周期可能是一两年，但是整个系列产品的生命周期往往长达数十年。而且经常会有开发工具已经终结，但是用这个开发工具开发的产品还在生存的问题，所以一个开发工具厂商如果想获得比较好的声誉和开发者的支持，就需要对产品进行长期的支持。即使开发工具已经退出市场，也要尽量满足开发者的支持要求。从这个角度看，选择一些开源产品作为产品的组成部分也是一个非常好的选择，比如JBuilder这次改投Eclipse门下就是一个比较好的选择。如果一个产品线确实要放弃，那么最好把他开源，让用户自己维护，这样可以保护用户在这个产品上面的投资，也可以保持公司的声誉。

最近，吕欣欣做了件比较有意思的事情，搞了一个Feedsky技术交流会，就是每周请一个技术人员到Feedsky去座谈。第一次是我去的，第二次是曾登高（可惜我错过了），这次是阿北。


长久以来的一个话题就是技术人员之间如何进行交流，尤其是不同的公司之间的技术人员之间怎么进行交流。很多人把这种交流的匮乏归结于技术人员的孤僻性格，这点我并不同意。实际上，就我接触的技术人员来看，他们大多是乐观向上的，风趣幽默的，甚至很多是很健谈的，跟传说中似乎有些差异。我认为这种交流的匮乏的原因在于缺乏机会和场合，缺乏跨公司的目的不那么功利一些的活动。

所以我说，吕欣欣做的很有意思，Feedsky的技术交流会就是一个提供这样机会和场地的活动。而技术人员之间我认为更多的是基于对技术的热爱产生的相互的敬仰，和交流的欲望。比如这次，听说偶像阿北要来Feedsky，我千山万水的就从南城飞奔到了太阳园。

关于这次的内容，我因为到得晚些，听得不甚全面，就抄袭下裴老师的总结吧：

阿北总结豆瓣开发的三点经验 （现场没有记录，凭记忆整理，可能有误，具体表述更不一定准确）：

• KISS。阿北在豆瓣之前任一公司CTO，负责开发企业 软件。受惯性思维的影响，在开发豆瓣之初设计的系统架构比较复杂，经过探索之后采用了 UI -> Data Object -> DB 的三层结构。事实证明，简单，不仅是 UI 的简洁，也包括系统架构的简单化，是豆瓣开发成功的关键所在。
  
  
• 永远 Beta。快速上线、不断完善的轻型开发模式被视为 Web 2.0 的典型开发模式，豆瓣在核心功能开发成功之后始终处于不断完善之中。这种模式虽然难免把问题暴露在用户直视中，但在用户的直接参与下的修改完善比“闭门修炼”效果更好。
  
  
• 注重用户体验。众口难调，不可能覆盖到全部用户的需求，所以只要照顾到多数用户就好。通过调研及悉心体验获知多数用户需要什么，如果搞错了及时调整。

在具体开发上，阿北遵循的许多做法都值得参考（个人总结，非现场顺序），例如：

• 选择 Python 开发的原因，是效率、效率、效率。
  
• 重点关注、率先实现核心功能，未及实现的逐渐完善。
• 网站应用结构要扁平，如果系统多人开发时应纵向切割。
• 程序员不要有惯性思维，如对数据库不熟悉就采取逃避态度。
• 在用户需求的理解上，程序员易自我中心，从程序实现思路出发。
• 乐此不疲地热爱 Coding 对于程序人员极其重要（参见豆瓣寻人）。

对于技术人员创业，阿北的经验也许更有启发。他认为一个好的想法很重要，但我从他的话里听出来把好的想法做出来才是最重要的。他说，某人拿商业计划书四 处找投资半年未果，如果用两个月时间做出点东西岂不是更有效，毕竟现在维持一个网站投入很小，只要生计不成问题就很容易做到。

可惜老白最后没来，不然我们一定能得到更多的启示。下次Feedsky技术交流会请的是韩磊，也是我的偶像，谈.Text下的分布式架构，看样子下个周末又不能睡懒觉了，呵呵。

Technorati Tags: 技术交流, python, 阿北, Feedsky