趁着年轻

原生的libtask库不支持epoll， 这样无法处理大量并发协程的情况，所以小改了下，让它支持epoll，允许大量并发协程运行。代码在这里libtask_epoll。

修改方法比较简单，就是把epoll_create， epoll_ctl， epoll_wait 几个函数的使用替换掉原来poll相关的函数，diff在这里。 阅读全文...

上篇文章写了libtask协程库实现的基本原理，最后说道协程编程一个很大的关键点是，程序员需要知道什么时候应该进行协程切换，什么地方需要异步I/O，什么地方的代码是顺序运行的等。

这里回顾一下具体哪些地方需要做协程切换，异步I/O： 所有可能会造成阻塞的操作，都必须进行异步IO处理，及时切换协程，绝对不能在协程里面做阻塞操作，因为阻塞了大家都阻塞了，就黄了。

顺藤摸瓜，上次的http压力测试小程序里面，协程执行函数fetchtask就是协程运行的主要函数，看下其实现： 阅读全文...

协程的概念不多说了，轻量级线程，其最大的优势就是协程之间的切换代价非常低，理论上是单线程运行，只是在应用层进行了上下文手动切换。

其最重要的实现函数是makecontext， getcontext， swapcontext 这一组函数，具体的协程上下文切换由他们完成。具体就不多说了，这些函数在glibc里面是已汇编的形式提供的，实际上做的工作就是讲各个寄存器，堆栈指针，指令指针等全部保存起来，或者进行切换，从而达到协程切换的目的。我们知道程序在CPU上运行的时候，注意依赖2个重要的东西： 阅读全文...

最近一个长连接服务经常被反馈连接失败，刚开始怀疑是网络问题，也就没有细查。今天仔细抓包分析了一下，原来碰到了在开启tcp_tw_recycle和tcp_timestamps的机器上，当多个客户端使用同一个外网IP( NAT）时可能出现连接建立不成功的坑，具体表现为客户端发送了SYN 包给服务器，服务器也收到了，但就是不回复SYN+ACK 给客户端，从而导致客户端重传SYNC，直至一分钟左右才能成功。

阅读全文...

刚才在测试一个服务器跟redis之间的连接自动重连机制时，碰到了个诡异的问题，epoll检测到了连接可用但程序总是不work，并且诡异的是redis被我停掉了，server竟然能够连接上来····
后来netstat -anp | grep 8379 查看了一下原来是server自己连接上了自己··· 阅读全文...

忍不住先吐槽一下，Libev里面的宏真T*D难看而且很多不必要的宏，好吧，其实他是为了性能。
估计介绍Libev的文章挺多的，这里只是个人记录一下，随便写点东西，libev代码还算简洁，虽然宏多了点，还有各种预定义变量等，今天花了几个小时下载了代码看看，简单记录一下。
之前没有用过libev，一般直接裸写的epoll，总结的话，libev的功能是： 支持将SOCKET，管道， 信号，以及定时器统一为通用的变成逻辑，给开发人员提供了一个简单高效的异步网络编程库。
阅读全文...

前几天碰到碰到一个线上redis CPU跑满的情况，基本无法处理正常请求了，刚开始以为是其他地方的问题，后来grep "Max open files" /proc/`pidof redis-server`/ -r  排查原来是启动redis的时候。ulimit -n 只有1024，从而无法接受新连接。

晚高峰时段段时间突发的大量请求导致某个时候redis连接数超过1024，从而listen sock 持续可读并且accept失败，从而CPU跑满，进而导致更严重的雪崩。 阅读全文...

没事碰到了librtmp库，这个库是ffmpeg的依赖库，用来接收，发布RTMP协议格式的数据。

代码在这里：git clone git://git.ffmpeg.org/rtmpdump

先看一段通过librtmp.so库下载RTMP源发布的数据的例子，从rtmpdump中抽取出来。使用的大体流程如下：

1. RTMP_Init主要就初始化了一下RTMP*rtmp变量的成员。
2. RTMP_SetupURL 函数将rtmp源地址的端口，app，等url参数进行解析，设置到rtmp变量中。比如这样的地址： rtmp://host[:port]/path swfUrl=url tcUrl=url 。
3. RTMP_SetBufferMS 函数设置一下缓冲大小；
4. RTMP_Connect函数完成了连接的建立，一级RTMP协议层的应用握手，待会介绍。
5. RTMP_ConnectStream总的来说，完成了一个流的创建，以及打开，触发服务端发送数据过来，返回后，服务端应该就开始发送数据了。
6. Download 其实是RTMP_Read函数的封装，后者读取服务端的数据返回。

阅读全文...

Mosquitto是一个IBM 开源pub/sub订阅发布协议MQTT的一个单机版实现（目前也只有单机版），MQTT主打轻便，比较适用于移动设备等上面，花费流量少，解析代价低。相对于XMPP等来说，简单许多。

MQTT采用二进制协议，而不是XMPP的XML协议，所以一般消息甚至只需要花费2个字节的大小就可以交换信息了，对于移动开发比较有优势。

IBM虽然开源了其MQTT消息协议，但是却没有开源其RSMB服务端程序，不过还好目前有比较稳定的实现可用，本文的Mosquitto是其中比较活跃的实现之一，具体在这里有目前的实现列表可供选择。

趁着大脑还没有进入睡眠状态记录一下刚才看代码学到的东西。我下载的版本是1.2.2版，在这里可以找到下载链接。 阅读全文...

今天在看MQTT协议文档，到处关于QoS（Quality of Service）的介绍，文档说如果没有收到对方的PUBREL等确认包，超时后server需要'delivery retry"， 一开始觉得理所当然的，重发嘛，丢包，正常。

然后就看到消息重发（Message delivery retry）这一章：

4.2. Message delivery retry

Although TCP normally guarantees delivery of packets, there are certain scenarios where an MQTT message may not be received. In the case of MQTT messages that expect a response (QoS >0 PUBLISH, PUBREL, SUBSCRIBE, UNSUBSCRIBE), if the response is not received within a certain time period, the sender may retry delivery. The sender should set the DUP flag on the message.

阅读全文...

回顾一下之前看的redis代码，脑子内存比较小，一会就忘了，所以备忘一下。
redis主体流程比较简单，init,listen, accept, read, write,基本就是这几步。下面简单介绍一下，当做备忘。 阅读全文...