深入理解send/recv系统调用！

int send( SOCKET s,      const char FAR *buf,      int len,      int flags );  
不论是客户还是服务器 应用程序 都用send函数来向TCP连接的另一端发送数据。
客户程序一般用send函数向服务器发送请求，而服务器则通常用send函数来向客户程序发送应答。
该函数的第一个参数指定发送端套接字描述符；
第二个参数指明一个存放应用 程序要发送数据的缓冲区；
第三个参数指明实际要发送的数据的字节数；
第四个参数一般置0。
这里只描述同步Socket的send函数的执行流程。当调用该函数时，send先比较待发送数据的长度len和套接字s的发送缓冲 的 长度 ， 如果len大于s的发送缓冲区的长度，该函数返回SOCKET_ERROR；如果len小于或者等于s的发送缓冲区的长度，那么send先检查协议是否正 在发送s的发送缓冲中的数据，如果是就等待协议把数据发送完，如果协议还没有开始发送s的发送缓冲中的数据或者s的发送缓冲中没有数据，那么 send就比较s的发送缓冲区的剩余空间和len，如果len大于剩余空间大小send就一直等待协议把s的发送缓冲中的数据发送完，如果len小于剩余 空间大小send就仅仅把buf中的数据copy到剩余空间里（注意并不是send把s的发送缓冲中的数据传到连接的另一端的，而是协议传的， send仅仅是把buf中的数据copy到s的发送缓冲区的剩余空间里 ）。 如果send函数copy数据成功，就返回实际copy的字节数，如果send在copy数据时出现错误，那么send就返回SOCKET_ERROR；如果send在等待协议传送数据时网络 断开的话，那么send函数也返回SOCKET_ERROR。
要注意send函数把buf中的数据成功copy到s的发送缓冲的剩余空间里后它就返回了，但是此时这些数据并不一定马上被传到连接的另一端 。 如 果协议在后续的传送过程中出现网络错误的话，那么下一个Socket函数就会返回SOCKET_ERROR。（每一个除send外的Socket函数在执 行的最开始总要先等待套接字的发送缓冲中的数据被协议传送完毕才能继续，如果在等待时出现网络错误，那么该Socket函数就返回 SOCKET_ERROR）
注意：在Unix系统 下，如果send在等待协议传送数据时网络断开的话，调用send的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。
通过测试发现，异步socket的send函数在网络刚刚断开时还能发送返回相应的字节数，同时使用select检测也是可写的，但是过几秒钟之后，再send就会出错了，返回-1。select也不能检测出可写了。
recv函数
int recv( SOCKET s,     char FAR *buf,      int len,     int flags     );   
不论是客户还是服务器应用程序都用recv函数从TCP连接的另一端接收数据。
该函数的第一个参数指定接收端套接字描述符；
第二个参数指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据；
第三个参数指明buf的长度；
第四个参数一般置0。
这里只描述同步Socket的recv函数的执行流程。当应用程序调用recv函数时，recv先等待s的发送缓冲中的数据被协议传送完毕，如果协议在传 送s的发送缓冲中的数据时出现网络错误，那么recv函数返回SOCKET_ERROR，如果s的发送缓冲中没有数据或者数据被协议成功发送完毕后， recv先检查套接字s的接收缓冲区，如果s接收缓冲区中没有数据或者协议正在接收数据，那么recv就一直等待，只到协议把数据接收完毕。当协议把数据 接收完毕，recv函数就把s的接收缓冲中的数据copy到buf中（注意协议接收到的数据可能大于buf的长度，所以 在这种情况下要调用几次recv函数才能把s的接收缓冲中的数据copy完。recv函数仅仅是copy数据，真正的接收数据是协议来完成的 ），recv函数返回其实际copy的字节数。如果recv在copy时出错，那么它返回SOCKET_ERROR；如果recv函数在等待协议接收数据时网络中断了，那么它返回0。
注意：在Unix系统下，如果recv函数在等待协议接收数据时网络断开了，那么调用recv的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。


本文来自ChinaUnix博客，如果查看原文请点： http://blog.chinaunix .net/u3/111204/showart_2179522.html

 

 

以上部分来源于网络，关于send/recv人云亦云的个人认为还可以的概念性描述——仅作日后参考

 

一下是本人工作实践遇到的问题及原因分析：

1，send/recv ： Bad file  descriptor    ——套接字描述符已被关闭(无效)，这是一段描述“It could be that you are closing the client socket before the thread gets a chance to run, or it could be that your thread is improperly setup.

”

2，send/recv：broken sigpipe  在读写时候(套接字缓冲区中并没有数据，一直等待)，如果出现网络异常，TCP/UDP协议无法将数据包传送到目的地，或者读写延迟时间已到，那么操作系统会抛给当前进程一个SIGPIPE信号，进程的默认处理是终止进程。

3，send/recv：connect reset by peer  由于网络异常，服务端主动关闭了通信链路(socket)，在客户端read之前

RST包已经传输到并被client socket接收缓冲区接受，那么此时客户端就会就会报这种错误

4， 以上2与3的区别：

    The client's call to readline may happen before the server's RST is received by the client, or it may happen after. If the readline happens before the RST is received, as we've shown in our example, the result is an unexpected EOF in the client. But if the RST arrives first, the result is an ECONNRESET ("Connection reset by peer") error return from readline.

5，服务端主动断开socket，不一定是网络不稳定，还有可能就是客户端一些错误操作导致服务端主动关闭，还有就是服务端压力过大导致自身关闭一些socket

 

本文可以结合来看：http://blog.csdn.net/HULIHONG/archive/2011/04/26/6363202.aspx，会有更深层次的理解