2013年转眼就要走完了，这是我第一次真正地感觉到时间流逝如此之快。回想这一年，似乎又是碌碌无为，什么也没做。不管怎么样，还是写一篇文章，纪念一下吧。
这一年生活上过得像个机器人：周一至周五上班，周六上午去超市买东西，下午看书或者运动，周日上午打扫卫生，下午休息。每一周几乎都是这样的日子，千篇一律。
工作上表现中规中矩，所有的项目都按时完成了，也没出什么问题，就不细说了。
英语学习也断断续续地坚持下来了，虽然自己并没有觉得有什么质的飞跃，还是会继续坚持下去的。因为英语水平已经到谷底了，坚持下去肯定只会一天比一天好吧。
技术方面上半年主要学习Lua，也就刚入门。下半年开始学习Golang，目前能写简单的程序了，但是要达到自己C语言的水平，还需多下功夫。另外最近一个月也开始看Dtrace，目前已经利用Dtrace解决了两个工作中的问题了，这也给了自己一点小小的成就感和坚持下去的信心。
展望2014年，还是希望自己能够在技术方面能更上一层楼吧，同时自己也已经30岁了，古人云：“三十而立”，自己也在考虑新的职业发展方向。好了，就写到这里吧。
这周在新的产品版本上线后，发现监控日志总是会报recv()返回error，并且errno是131（ECONNRESET）。查了一下man手册，发现并没有说recv()会返回ECONNRESET，于是自己便打算一探究竟。想到最近正在学习Dtrace，于是便写了下面这个简单脚本（check_recv.d）：
#!/usr/sbin/dtrace -qs
syscall::recv:return
/(int)arg0 <=0 && pid == $1/
{
printf("recv return: tid=%d, arg0=%d, errno=%d\n", tid, arg0, errno);
}
第四行是触发探针条件：当recv返回0或者-1并且进程号等于输入监控的进程号。
第六行是输出：线程ID，recv()返回值，errno。
使用方法 ：check_recv.d 19771（监控进程号）
通过运行脚本，我发现其实recv()返回的是0，而errno也是0，那么为什么监控日志会输出errno是131呢？我又查了一下这个版本新加的代码，发现了下面的逻辑：
if (recv() <= 0)
{
log(errno)
}
原来在recv()返回0时，也会输出errno。而在recv()返回0时，是不会更新errno的值，只有在recv()返回-1时，才会更新errno的值。所以现在监控日志里的errno其实是以前某个系统调用错误时设置的errno。所以代码应该改为：
if (recv() < 0)
{
log(errno)
}
问题解决！
客户端—服务器（Client-Server）是我们平时最常见的通信方式，本文就对这一通信模型做个简单介绍。
（一）TCP连接方式：短连接方式？长连接方式
目前，多数的客户端—服务器选择TCP做为传输层协议，也有少数选择UDP或SCTP协议的。而TCP连接有两种工作方式：短连接方式（Short-Live Connection）和长连接方式（Long-Live Connection）。
（1）短连接方式：
当客户端有请求时，会建立一个TCP连接，接收到服务器响应后，就断开连接。下次有请求时，再建立连接，收到响应后，再断开。如此循环。这种方式主要有两个缺点：
a）建立TCP连接需要3次“握手”，拆除TCP连接需要4次“挥手”，这就需要7个数据包。如果请求和响应各占1个数据包，那么一次短连接的交互过程，有效的传输仅占2/9，这个利用率太低了。
b）主动断开TCP连接的一端，TCP状态机会进入TIME_WAIT状态。如果频繁地使用短连接方式，就有可能使客户端的机器产生大量的处于TIME_WAIT状态TCP连接（UNIX系统下，可以使用netstat命令来查看）。
（2）长连接方式：
客户端和服务器建立TCP连接后，会一直使用这条连接进行数据交互，直到没有数据传输或异常断开。在空闲期间，通常会使用心跳数据包（Keep-Alive）保持链路不断开。目前长连接方式应用范围比较广泛。
（二）消息交互方式
（1）一个请求，一个响应
这种消息交互方式如下图所示：
当客户端发出请求后，程序就阻塞在那里，直到收到服务器的响应或者超时。很多对数据库的访问方式都是这样的（像Redis的C程序客户端hiredis）。
（2）多个请求，多个响应
这种消息交互方式如下图所示：
这种方式下，客户端一次可以发送多个请求，而每个请求会带有一个消息标示（Message ID）。这样在客户端收到响应后，就可以根据响应的消息标示，和请求对应起来。
