TCP处理第一次连接断开，再次连接处理

主要参考这个文章：

http://blog.csdn.net/eric0318/article/details/51087513

盗一个图：

最近接到个任务：接收机实现自制板卡固件升级的功能。

据板卡部所说，网口升级的话，需要连接两次：板卡做服务器端，接收到changemode会关闭掉现在连接程序，,去启另一个update程序，这时应当去重新连接。

由于属于服务器端close掉TCP连接，那么本升级程序再去read该连接时，读取为0。
并且处于CLOSE_WAITE状态，须调用close函数，发送FIN分节，
确保本程序的该TCP 过程结束。

//因为板卡服务器端close掉连接后，处于FIN_WAITE状态
//初步猜测，在服务器发送来FIN分节后，client的系统自动发送了ACK
//则服务器虽然关闭了，但系统维护的该套接字应当处于FIN_WAITE2的状态，等待client发送FIN分节
//如果收到客户端的FIN,那么服务器那个套接字会处于TIME_WAITE状态，
//这个状态等待的时间，初步查资料是2MSL，
//而如果服务器套接字选项没有选择一些选项(SO_LINGER或者SO_REUSEDDR)
//那么服务器端监听同一端口在2MSL时间内无法接受新连接

//那么，如果我的程序能够先板卡服务端执行close,那么过程就应当是"优雅"的退出，
//尽管我这边第一个连接会处于Time_Waite状态，但是由于客户端连接时，系统随机分配端口
//所以不会对第二次连接造成影响。

稍微发些牢骚：

1、接收到任务后，所给材料不全，折腾来折腾去，最终用已有的串口工具进行串口检测数据，然后模拟中间过程。

2、由于接收机正常程序占用了串口，要干掉相应程序，另外编写升级程序。先利用网页将文件推送至cgi程序，CGI启动升级程序，然后kill相关程序、开始升级过程。

3、利用网口升级，由于接收机底板一个网口与板块网口直连，需将该两网口设为同一网段，才能TCP通信。中间遇到问题，浪费了2天，最终发现是多焊接一个电阻，坑.....