年关临近，又得开始准备年终总结了，我先简单罗列一下，以便写总结的时候有个参考（仅限于产品部分）。

元旦之后一个多星期又开始搞Hermes相关的一些功能，但是说实在的，我对此真的不太积极，而这主要的原因是在于，我认为（一直认为）这并不是“走在一条正确的道路上”，而且，I don’t in charge of this product。

众所周知，STUNT相对于STUN及成功率是相当的低，而且相对来说，中间流程控制起来会更加的麻烦。但是事实上，虽然我在项目周会或者其他多种场合说 明和强调，Hermes却一直在沿着这条我“个人”认为不正确的道路上走下去，而且越走越远，甚至开始衍生出其他许多这样那样的“花头”来，如：
1. 为节省打洞，把原来两开的两种socket（一种用于信令及控制，一种用于视频的传输）进行合并，以复用socket。
2. Tunnel

这如果是在其他“环境”下，可能直接就被枪毙了，可是，我们已经花了很多人力来朝着这个方向来做基于这么一个思想的东西。不对，不是一个，而是很多个衍生 产品。当然，需要去做这些衍生产品，以及这么急着在这个不确定的、甚至明知很滥的也不可能规模化的基础上去做的原因很大一部分是在于市场的需要，或者说是 那些Board members的要求。

可这实在是让人受不了了，再加一句我“个人”的见解，这些东西即使做出来到头来很多做法也都最终会被推翻掉的，再过阵子，大家回头来看这堆东西，说不定就会称之为“垃圾”，在一个宝贵的时间里做出来的“宝贵”的垃圾。可是，你又能怎么办呢？

我先来数一数这N宗罪（不仅限于Hermes，所以题目也要改一下）。虽然在各种场合，我已经说了太多遍了，但也许我也还是得再说。

第一宗罪：似乎天下只有TCP，没有UDP。
从绑定单一的8000端口，到程序的实现，无一不是朝这个方向去做。
第二宗罪：太多的历史包袱，每个版本都在版本兼容性上花费一极大的力气，却导致许多规划、计划都无法实施。
在iNVR/eLook项目上，其实我一开始是有很多改善的措施，并且相当一部分的功能都已经实现，但由于要兼容各种旧版本的客户端，并且要兼容Windows的各种产品，结果后来又费力把已经实现好的功能拿掉，改成跟
第三宗罪：又想提升打洞成功率，又不想花时间去研究UDP及STUN的解决方案。
虽然说，其很大一部分原因是因为其他项目一直delay，但是既然Hermes项目一直在推进，为什么就不能优先去把Hermes的路给走对了呢？

未完，待续。想起来再补充。