今天和达达一起看电影：名探偵コナン 沈黙の15分 (2011)
回家的时候，她突然冒了一句，好浪漫啊~~~~~~
我立马被雷到了，于是问她说什么..
她说：每当我看完我喜欢的电影，出来的时候是晚上（今天貌似天气很好，月亮很亮），坐在车里，我就会觉得浪漫
我：。。。。。。
达达：不要以为只有大人才有浪漫，小孩子的浪漫也是实实在在的啊
我：（心里默默接着说 啊啊啊啊啊啊啊啊啊）
达达又接着说：小孩的浪漫很单纯，到了青春期的浪漫。。。。（她顿了顿）很奇怪
====
将来不知道哪个臭小子会第一个取代她老爹陪看电影载人回家的重任...哼哼
她很想去看新片丁丁历险记，于是就把影院里的预告片看了好几个轮次，也顺带看了《猩球崛起》的预告片。。。
她评论：这个片子告诉我们，科技发展太快也不是一件好事..
附最近邱可心读的贾尼.罗大里的一首儿童诗歌：《需要什么》
做一张桌子，需要木头； 要有木头，需要大树； 要有大树，需要种子； 要有种子，需要果实； 要有果实，需要花朵； 做一张桌子，需要花一朵。
【Update：最近两个月，面试的重点是社招，2012年毕业生争取年底的时候统一进行笔试和面试】
搜狐将在武汉成立工程院，我目前负责武汉工程院的筹备和初期建设工作。武汉工程院也会逐步配置独立的产品和运营团队，争取早日主动驱动业务增长。
初期的办公地点离华科大不远，办公室预计元旦前可交付使用。目前期望能迅速招到4-5名 Python 工程师，慢慢接手邮件系统的一些开发任务；2012年能总共到20-30名Python工程师这样的规模..
JD 就不细写了，如果市场提供不了这个数目符合要求的工程师，我愿意自己来培养.武工院是搜狐一个长期的战略存在
除了Python工程师，我这里也需要前端JS工程师、Java工程师、测试工程师；需要产品经理，项目经理，UI/UE设计师...
不管你是人在武汉，还是正在北京想逃离“北上广”，都可以给我回邮件 qiuyingbo@sohu-inc.com我们期待您的加盟
老韩说：未经许可，严禁转载... 哈哈，所以我只转载一个链接: 秀码趣：Bleeding Edge版V8引擎的内存使用评测
这篇文章背后是我们暑期实习生训练营的成果，非常高兴看到他们的成长！
以后俺们如果开始发布 sohu developer blog 的话，除了 linux@SOHU 之外，看来可以增加一个 NodeJS 的专栏.. :)
这个数据是从今天的彩信报上看来的，应该是转自中国青年报，貌似是波士顿咨询集团的数据..
国庆期间租了一本《丰台生产方式》看，里面说二战前美国的劳动生产率是德国的三倍，而德国是日本的三倍——就是说美国劳动生产率是日本的9倍；战败后，麦克阿瑟在日本说，美国的劳动生产率是日本的八倍
http://haraka.github.com/
按照技术难度，咱们来发展它依次有三个可能：
1. 作 out-bound 的 MTA，它的定制性比 postfix 应该是容易些。由于某些原因，向外投递如果出现问题需要一些更复杂的处理，而不是简单的产生退信了事。
2. 作 in-bound 的 MTA，尤其是如果要重新开始实现一个商用的邮件网关的话，应该考察一下这个项目。
3. 如果已经能当 out-bound，又搞定了 in-bound，那就作一个整套的 Windows 邮件系统吧。
另外刚刚又搜索了一下 Python 的 MTA，貌似最靠谱的是 http://www.lamsonproject.org，但是也有一年没有更新了
UPDATE: Python 最新的进展是 https://github.com/bcoe/smtproutes
有了i909后，我无意中装了一个淘宝，然后在这个app里面看到一个安卓专区，点进去一看，排名第一的手机是：中兴v880
再点进去一看，不到900的价格，大屏幕，高分辨率，难怪卖得那么火。
后来又看到了所谓中兴三剑客，针对于 TD、CDMA，中兴又有类似的两款手机。
再后来又看到了华为C8650，天翼定制机，外形和 iphone 3GS 几乎一模一样，也是 3.5 屏幕 + 320x480 分辨率，Android 2.3 系统，但是这个只卖 800，传说 19天内已经卖出去了30w部
不管电信联通如何厮杀，不管华为中兴怎么血拼，高通都是赢家。中兴v880用的是高通MSM7227，华为C8650是MSM7627，甚至中兴对抗C8650的N880s也是MSM7627...
联想刚刚推出了1000元的Android平板，我是国庆期间在天津岳父家的电梯里看到的广告招贴，很受震撼。
去年9月份我写了一篇研究了一下山寨Android平板的芯片，现在震惊于一线厂商的价格策略，于是又去专门研究了一番电容屏的低端平板：
当然软硬件还要调优，电池也是一个很大的瓶颈，WIFI还不普及，但是看起来已经没有什么能阻挡在2012年平板的大爆发了...除了Android自己——手机
September 13, 2011
几乎所有google的服务都是通过 Internet 交付给用户使用，因此该公司特别有动力改进网络的运行模式。在2011召开的Linux Plumbers Conference featured presentations的网络会议上，三个google的工程师各提出了一个对网络有显著改变的建议。从他们三个人的建议可以看出，networking 还有很大的改进空间。
Proportional rate reduction
这个“拥塞窗口”主要取决于TCP发送者的想法：在中间环节超载的情况下，多少的数据能够被传送至末端。丢弃包常常意味着拥塞窗口过大，因此需要TCP正常实现过程中减少窗口当丢失发生时。但是减少拥塞窗口，就会减低性能；如果丢包仅是一次性事件，减少窗口大小是完全没必要的。RFC3517描述了一种算法，以使一次丢包后，加快连接速度。但是Nandita Dukkipati说，我们可以做的更好。
根据Nandita的说法，Google 的网络会话出问题的大部分原因集中在一个点上，它将导致花费7-10倍的时间才能完成会话。RFC3517是这个问题的一部分。这个算法当一次包丢失后，会立即减少一半的拥塞窗口，意味着发送者必须等待ACKs一半在传输途中的包（如果丢失包后拥塞窗口还是满的）。这就导致发送者将保持更长的等待时间。在简单的情况下（单个包丢失在长时间的传输过程中），这种做法是足够好的。但是在处理短数据流或很大比例的包丢失时，将阻碍工作。
现在的Linux系统没有使用严格的RFC3517。它被一个改进的算法“率减半”所代替。拥塞窗口不会立即减半。一旦 TCP 开始尝试恢复丢失包，每个ACK（主要是告诉末端两个包的接收者）将引起拥塞窗口大小减少。在传输过程中的全套发生上述过程，窗口大小将减半，但是发送者将持续发送（低速率）。这种方案最终的结果是减缓数据流和降低等待时间。
但是率减半还有提升空间。ACKs依赖于自身；延长的损失将显著引起拥塞窗口数量的减半和恢复的缓慢。这个算法也没有处理拥塞窗口的速率达到最高的可用值的过程，直到整个恢复过程完成后，速率才到达最高值。因此这将花费更长的时间来返回到最高速率。
成比例速率减少算法采用了一种不用的方法。第一步就是评估和计算传输的数据量，然后根据拥塞控制算法，计算拥塞窗口数量是多少。如果在管道中的数据量小于目标窗口的值，系统将直接进入TCP慢启动算法来备份窗口。然而当连接中发送大量丢失时，边开始重建窗口，而不是长时间匍匐一个小窗口。
相反如果传输的数据量至少达到了一个新的拥塞窗口，一个相似的率减半算法将被使用。相对新的拥塞窗口计算实际的减少量，而不是严格的减半。对于大和小的丢失，注重于使用评估的传输数据量，而不是请求的数据量。这使得恢复更加顺利和避免不必要的窗口数量的减少。
那多少是最合适的呢? Nandita认为，根据google在一些系统上已经运行的实验结果显示，平均等待实际减少3-10%。恢复实际减少5%。这个算法已经广泛应用于google服务器上；该算法也被3.2开发周期所合并。更多的信息请查看这份 draft RFC。
TCP fast open
打开一个TCP连接需要一个three-packet 握手：客户端发送一个SYN（连接请求）数据包，服务端返回一个SYN-ACK（确认）响应，以及最后由客户端发出的一个ACK（确认）。直到握手完成，连接才可以传送数据，所以握手机制在每个连接都有一个不可避免的开始延迟。但是，问问Yuchung Cheng，如果想要在握手数据包中携带数据信息将会发生什么。对于一些简单的事务，例如一个接下来要发送一个页面内容的HTTP GET请求，伴随着握手数据包发送相关联的数据将会消除延迟。这个想法的结果就是TCP fast open的设想。
RFC 793（关于TCP的）确实允许数据包含在握手的数据包中发送，数据被限制为在握手完成之后再被 tcp 栈传递给应用程序。这样就可以通过避免最后一次请求来加速一次TCP连接发送数据的进程，但是还有一些障碍需要解决掉。一个很明显的问题就是会加大SYN泛滥攻击的几率，即使它们只影响内核后果也足够糟糕；如果每个接收到的SYN数据包都要占用应用程序的内核资源，那么拒绝服务的可能性就会变得很大。
Yuchung叙述了一种快速打开的方法试图解决大部分的问题。第一步是每个服务器创建一个 per-server secret，然后根据每个客户端的信息 hash，给每个客户端生产 per-client cookie。当客户首次发起 TCP SYN 请求时，这个cookie被作为一个special option包含在 SYN-ACK数据包中发送到客户端；客户端可以保存它，然后在未来的fast open时利用它。首先得到cookie的需求是一种低端的防止SYN泛滥攻击的方法，但是它确实让攻击变得有些困难了。另外，server端的secret可以相对频繁的更改，并且，如果当server发现有很多的连接时，fast open将会被禁用，直到连接数目回归正常。
一个仍然存在的问题是，互联网上大概有5%的线上系统将会丢弃那些包含了未知option数据的SYN数据包。这种情况下TCP fast open就无法使用了。客户端必须记住那些fast-open SYN数据包没有发送成功的cases，以后再遇到这些cases就使用普通打开。
缺省情况下fast open不会发生；连接双方的应用程序都必须特地的要求使用它。在客户端，sendto()系统调用就是用来请求一个fast-open连接；伴随着新的MSG_FAST_OPEN标志， 它的功能就像是connect()与sendmsg()的结合。在服务端，伴随着TCP_FAST_OPEN option 的setsockopt()调用将会允许fast opens。不管哪种方式，应用程序都不用担心去处理类似fast-open cookies这样的问题。
在google的测试中，TCP fast open已经被证实可以减少4%到40%的页面载入时间。自然的，在连接往返时间开销很大的情况下这项技术效果最好；延迟越高，移除它的价值就越大。很快，一个实现了这个特性的patch将会被提交。
Briefly: user-space network queues
之前的两个讨论都是在关注提高数据在网络上传输的效率问题。Willem de Bruijn则是关注与在本地主机上的网络进程。特别是，他是在使用高端的硬件工作：高速的网络连接，数目众多的处理机，并且，更重要的是，它拥有可识别特定流然后直接把包传入特定连接队列的智能网络适配器。当kernel感知到这个数据包的时候，它早已被接收并放置在合适的位置等着应用程序来请求数据了。
实际的对数据包的处理工作将会在应用程序的上下文环境中执行。所以"合适的位置"这里还包括了正确的上下文和正确的CPU。在软件IRQ级的中间处理就省略掉了。Willem甚至描述了一个新的接口，靠它应用程序可以通过一段共享内存段直接从kernel接收数据包。
换句话说，这段讨论描述了几种网络通道的概念，通过它们数据包被尽可能近的推送到应用程序。还有大量的细节问题需要涉及，包括为了类似防火墙等原因导致的通道挂起。利用 sysfs 向用户空间发送数据包的建议很难通过评审。但是这项工作最终可能会达到一个普遍有用的地步；有兴趣的人可以在 the unetq page 处找到patches。
本站的feed
最新评论