本日主要工作
昨天解决的是so的编译和链接问题，今天则主要解决的是运行和测试，测试的时候发现httpclient发送的http请求，而没有收到任何消息，提示的信息为EINPROGRESS，也是有Operation is onprogress。这个提示很有迷惑性，一时还镇不知道错误在哪里。于是开启了strace去看下中间发生了哪些事情。
strace的命令使用如下：
strace -p pid -o strace.out
得到的结果如下send，fcntl epollin，recv。
也就是说并没有过多的一些系统调用，那么还是怀疑没有收到任何数据。此时用tcpdump抓一个正确的包，来对比错误原因是什么
/usr/sbin/tcpdump -i eth2 -w eth2.pcap
对比了一下，
Accept为/,
content-type为x-www-xform-urlencode
这里我填写的是application/json，另外缺少content-length。添加了后就正常了。
结论是http的请求拼写的不正确。另外还有一个delete channel的时候有个错误是apply-error而不是正常的error。找了半天原来是bizId的I要为小写bizid。非常的费眼睛。
x-www-form-urlencode是什么
- 早先由于get的参数长度有限制于是可以采用post，然后将参数用x-www-form-urlencode编码放入body中。
采用POST的话，既可以在uri中带有queryString也可以将数据放在body中。body内容可以有多种编码形式，其中application/x-www-form-urlencoded编码其实是基于uri的percent-encoding编码的，所以采用application/x-www-form-urlencoded的POST数据和queryString只是形式不同，本质都是传递参数。
在tomcat的Request.parseParameters方法里，对于application/x-www-form-urlencoded是有做判断的，对这种编码会去解析body里的数据，填充到parameters里，所以后续想再通过流的方式读取body是读不到的(除非你没有触发过getParameter相关的方法)。
这个会触发web服务器的getParameter的行为？
strace的原理以及一些使用
strace的原理主要是调用了ptrace，而gdb也是通过ptrace这个系统调用来完成的。以前被问到过gdb的调试原理，没答上来，确实还是没有去深入研究。
ptrace的调用过程一般如下：
父进程fork子进程，
子进程调用ptrace（PTRACE_TRACEME）来告诉操作系统自己可以被trace
。然后子进程调用syscall系统调用的时候将会被暂停，
系统通知父进程sigtrap。
然后父进程通过ptrace eax*4的地址，拿到系统调用号，然后子进程继续执行在syscall
结束的时候告诉父进程，父进程拿到执行结果。这就是一个基本流程
在Linux系统中，进程状态除了我们所熟知的TASK_RUNNING，TASK_INTERRUPTIBLE，TASK_STOPPED等，还有一个TASK_TRACED。这个应该是有关系的。
参考资料
2.ptrace的原理2
http://blog.csdn.net/kernel_learner/article/details/7335791
