有个梨UGlee
2019-11-19 00:00:00 发布
回答一下前面说的问题。

duplex stream的两个方向的结束，EOF，是除了destroy之外任何错误或者end结束之后都该抛出的，原则上和connect无关。connect和close并非成对关系。

为什么？

connect和close的成对关系是socket资源意义上的，就像文件描述符的open和close。但是stream的设计里，这个流是怎么来的，如何销毁回收资源，不在stream的通用接口设计考虑范围之内。

例如node的fs.createWriteStream，在创建stream之后就可以pipe数据进去，而不是要等到这个stream真的打开拿到文件描述符。

网络连接也是一样的，connect就相当于文件描述符拿到了。但是良好的设计不应该要求使用者自己去block，等到连接创建之后才开始发送数据。所以从这个意义上说，connect是side band消息，不是in band数据。

close只意味着一个真正的结束，在close之后不会再有任何事件发出。如果有什么东西要在这里继续，这是最好的一个代码位置。

node的stream都是为了pipe设计的。pipe本身相当于成功路径，不管错误情况。如果一切顺利，所有其他事件都可以忽略。如果出现错误，那就全部报废。所以使用和实现的原则是：

全路径都要保证end和finish必须emit，这样所有的stream都可以正确完成自己的资源维护，当然这不意味着全部数据流都是正确传输了，只要有error抛出，你就可以假定是全失败了。

这个设计哲学规避了考虑connecting和connected的状态差异以及由此带来的编程问题，尤其是各种等待和同步。

从这个设计可以看出node的设计哲学，是乐观主义的。全部搭好一个流组合，如果没问题，谢天谢地，如果有问题，再来一次，但坚决不去深入到细节研究corner case的状态组合。可以说是非常简单暴力和实用主义了。

但大道至简，正是node和js的聪明之处。