TCP 简易代码

基础知识：

1、阻塞IO   

send/recv    若成功则为读入或写出的字节数， 返回 0则表示对端关闭连接即对端执行close，0 == EOF  

失败返回 -1，并设置错误码，  返回 -1必须做处理的意义存在于(目前所知)，当心跳包超时，服务端心跳回调线程需close(connfd)关闭套接字，这样才能控制recv返回 -1，并作相应资源释放和 退出该任务处理线程，否则当close()之后，recv 返回-1未得到处理，因此recv_message()会死循环在 for (; ;)中  

 服务端close(connfd)、close(sockfd)，会导致客户端程序退出，然后客户发送FIN 此时服务端理应recv 返回0(EOF)，但是recv会直接返回 -1，并不会接收客户发来的FIN (因为此时connfd已经关闭了，所以recv 不会返回0 || EOF)，所以导致了 recv_message 自分装的为避免粘包recv函数   for(;;)死循环

2、非阻塞IO 

待写。

调试心得：

•    若在该套接字上没有服务监听，或服务程序根本为运行，硬错误，connect会立即返回ECONNREFUSED
•    在accept之前close(sockfd)，accept会直接返回-1 并且报错：accept failed: Bad file descriptor

 但是在 accept之后   close(sockfd)（开另一线程定时关闭套接字），客户程序依然能够connect到该服务器上，并正常收发

（说明accept以后，程序阻塞于accept中，这时另一个线程关闭sockfd，对此时的accept并没有影响，accept已经阻塞在此了）但是在关闭套接字以后，再次调用执行accept会出错：accept failed.: Bad file descriptor

•    close(connfd)之后再次调用 recv， recv会直接返回 -1，错误码为 recv failed.: Bad file descriptor
•    如果想退出 accept 就调用 close(sockfd)，如果想继续监听accpet，但是退出本次与客户连接，就close(connfd)
•    本次测试不使用select，直接accept，ctrl+c退出客户程序，服务程序不退出循环进入accept阻塞等待连接（但是服务端do_work线程同样会处理close(connfd)，connfd = 4），客户再次发起连接时，服务端返回的connfd 加了 1即 connfd = 5，再次调用ctlr+c杀死客户端，再发起连接，服务端的connfd = 4 又回到了4， 多次测试4、5循环得到connfd，但是使用select，每次退出客户程序再次连接，connfd 都一样(客户每次退出，服务端do_work正常处理 close(connfd)) 不关闭监听套接字 close(sockfd)，为了一直处于accpet状态下
• 还有一种情况不清楚为什么，就是当 服务端直接处于accept(无select)状态下，先关闭close(sockfd)，客户发起连接时，这一次会connect成功，并且开始发送数据，(是因为accept本身已经处于监听状态了，close对于这次的accept没有影响，只会影响下一次accept)，当服务程序进入到accept时，判断已经关闭了sockfd，因此直接返回 -1。(若服务程序此时完全中止退出，客户程序也会退出，在recv调用的时候，但此时服务端套接字早已关闭，客户端recv也收不到FIN或者RST，但不知什么原因直接退出了，判断客户recv() 返回值 <= 0 的时候增加了打印，但程序未打印出，直接中止客户程序，不明原因，不过正常情况下，不会close(sockfd)后依然去监听的，所以不用担心这个问题)   

       原因是返回 客户程序      send failed: Connection reset by peer 形成原因：

1，如果一端的Socket被关闭（或主动关闭，或因为异常退出而 引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常(Connect reset by peer)。

Socket默认连接60秒，60秒之内没有进行心跳交互，即读写数据，就会自动关闭连接。

2，一端退出，但退出时并未关闭该连接，另一端如果在从