我上次假期烤了一个烤肉pizza,因为和面的时候出了点意外(水太多),肉没有预处理,而且选的鸡肉不是鸡胸肉,骨头太多。另一方面,烤箱温度和时间都没控制好,因此最后吃起来一般般。吸取了上次的经验,这次把过程给记录了下来,虽然和面仍失水准,并且最后的结果虽然有点焦,但吃起来还是不错的!
我把我的步骤大致说说。
我上次假期烤了一个烤肉pizza,因为和面的时候出了点意外(水太多),肉没有预处理,而且选的鸡肉不是鸡胸肉,骨头太多。另一方面,烤箱温度和时间都没控制好,因此最后吃起来一般般。吸取了上次的经验,这次把过程给记录了下来,虽然和面仍失水准,并且最后的结果虽然有点焦,但吃起来还是不错的!
我把我的步骤大致说说。
天宇找了个好玩的2D纸娃娃系统,叫做charas.EX.
工具很不错,虽然有点儿简陋,不过想想已经十年历史了也挺正常的。charas.EX带了很多像素风格的素材,可以满足很多小游戏的需求。
看了一期BBC美食纪录片,我也顺便介绍一下广东的饮食文化。
广东料理(Cantonese Cuisine)是我们俗称的粤菜,也包括了在潮汕那一带的客家菜。有句话说“四条腿除了板凳,带翅膀的除了飞机,广东人都敢吃”,虽是高级黑,但广东的饮食的确很丰富,这是因为很久以前这边很缺乏食物,所以吃的东西比较广。
TCP接收到数据之后会写入到TCP本身的Buffer里,然后会拷贝到应用层(亦即我们的应用程序)的接收Buffer中。在满足以下条件时,TCP接收Buffer的数据会被写入到到应用层的接收Buffer并且recv()返回:
应用层的发送Buffer把数据写入到TCP的Buffer中:
如果应用层的发送Buffer超过了TCP发送Buffer的大小,就会发生阻塞,直到把所有数据写入到TCP的Buffer中才会返回。
在TCP进行Nagle优化时,如果发送的Buffer太大并且满足了Nagle算法优化场合,TCP就会先发送部分数据,这时候对端就会出现我们平时所说的粘包或者残包,需要在业务上进行拼接和解析。
这个系列到此结束了,主要讲述了TCP协议的一些比较底层的理论问题,也许大多数人甚至是从事网络通信(如写服务器)的程序员也不一定了解过,工作上也几乎很少用到。不过有必要建议还是花点时间了解一下,不一定要深究,但至少对得起自己的情怀和职业呀。。
参考书籍:《TCP/IP详解》
画一个流程图方便理解上一章的内容:
(1) 发包的时机
每个ACK都有可能触发发包,是否发包取决于根据’(2)’中的公式所算结果是否大于零。
接收端的基本行为有:接收数据包、回复ACK,适当时将数据送往应用层缓冲区。
(1)一般情况下收到2个包回1个ACK,除非第二个数据包在200ms内没有收到(这种情况下所回复的ACK被成为Delayed-ACK, 200ms定时器则称为Delayed-ACK Timer)。
(2)如果出现丢包情况,对于后续收到的每一个数据包则重新回复ACK.
(3)重传的数据包收到之后,会和之前收到的所有数据包一起回复ACK.
(4)还有就是,满足以下任何一个条件时数据都会被送往应用层缓冲区:
Flatbuffers的编译器有个-c参数选项,这个选项需要一个个传入.fbs文件的路径,给维护带来很大的不便。昨晚改了下flatbuffers的编译器代码,把cpp代码生成器生成的部分变量名以及生成的cxx文件后缀改掉了,这样看起来违和感没那么强,符合Coeus的代码风格。本来也想把-c选项改成支持’‘通配符的,这样便可以肆无忌惮地给出一个目录让编译器自己去遍历.fbs文件。但回头一想这似乎不应该是编译器做的事情,所以就把这个想法搁掉了。于是写了个简单的python脚本(2.7.x),用来维护fbs文件并且把生成的cxx文件输出到指定目录。
FlatBuffers提供的Schemas (又叫IDL, Interface Definition Language) 语法在于c-like, 无论对于C语言用户还是其它IDL用户来说都很容易掌握。