关于网络编程 （一）socket 杂记整理

 

Socket send函数和recv函数详解

1.send 函数

int send( SOCKET s, const char FAR *buf, int len, int flags );  

    不论是客户还是服务器应用程序都用send函数来向TCP连接的另一端发送数据。客户程序一般用send函数向服务器发送请求，而服务器则通常用send函数来向客户程序发送应答。

    该函数的第一个参数指定发送端套接字描述符；

    第二个参数指明一个存放应用程序要发送数据的缓冲区；

    第三个参数指明实际要发送的数据的字节数；

    第四个参数一般置0。 

    这里只描述同步Socket的send函数的执行流程。当调用该函数时，

   （1）send先比较待发送数据的长度len和套接字s的发送缓冲的长度， 如果len大于s的发送缓冲区的长度，该函数返回SOCKET_ERROR；

   （2）如果len小于或者等于s的发送缓冲区的长度，那么send先检查协议是否正在发送s的发送缓冲中的数据，如果是就等待协议把数据发送完，如果协议还没有开始发送s的发送缓冲中的数据或者s的发送缓冲中没有数据，那么send就比较s的发送缓冲区的剩余空间和len

   （3）如果len大于剩余空间大小，send就一直等待协议把s的发送缓冲中的数据发送完

   （4）如果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也不能检测出可写了。

 

2. recv函数

int recv( SOCKET s, char FAR *buf, int len, int flags);   

    不论是客户还是服务器应用程序都用recv函数从TCP连接的另一端接收数据。该函数的第一个参数指定接收端套接字描述符；

    第二个参数指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据；

    第三个参数指明buf的长度；

    第四个参数一般置0。

    这里只描述同步Socket的recv函数的执行流程。当应用程序调用recv函数时，

    （1）recv先等待s的发送缓冲中的数据被协议传送完毕，如果协议在传送s的发送缓冲中的数据时出现网络错误，那么recv函数返回SOCKET_ERROR，

    （2）如果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信号，进程对该信号的默认处理是进程终止。

 

 

1、  为了增加效率，可以考虑采用无异常的函数
在.net2.0中Socket.Send,Socket.Receive有了无异常的函数
Socket.Send(Byte[], Int32, Int32, SocketFlags, SocketError)
Socket.Receive(Byte[], Int32, Int32, SocketFlags, SocketError)
减少不必要的异常，就等于增加效率。

2、Socket.Connected不是当前的Socket状态
MSDN原文：获取一个值，该值指示 Socket是在上次 Send还是 Receive 操作时连接到远程主机。
应当如何解决呢？

同样MSDN也告诉了我们：
Connected 属性的值反映最近操作时的连接状态。如果您需要确定连接的当前状态，请进行非阻止、零字节的 Send调用。如果该调用成功返回或引发 WAEWOULDBLOCK错误代码 (10035)，则该套接字仍然处于连接状态；否则，该套接字不再处于连接状态。
3、要用Socket.Poll判断是否可以接收，不要用Socket.Available
虽然Socket.Available可以偷窥到当前Recv缓冲区字节数，而且Available是Poll速度的两倍，但是MSDN说到：如果远程主机使用 Shutdown 方法关闭了 Socket连接，并且所有可用数据均已收到，则 Receive方法将立即完成并返回零字节。
所以当网络断开的时候单纯使用Socket.Available判断是否recv到数据会存在不知道客户端已经断开Bug
补充：不推荐使用Socket.Poll对Socket的列表遍历，应当使用Socket.Select（或者其他模型），Socket.Poll是对Socket.Select的封装，执行Socket.Poll耗时是非阻塞Socket.Recv的三倍。
4、非阻塞模式不能采用Receive的返回值表示是否断开
第3条说道：如果远程主机使用 Shutdown方法关闭了 Socket连接，并且所有可用数据均已收到，则 Receive方法将立即完成并返回零字节。但这并不能阻塞模式说明Socket已经断开，这一条和C的recv函数不同，需要特别注意。需要判断out出来的SocketError，当不为SocketError.Success、SocketError.Interrupted和SocketError.WouldBlock时就可以认为网络已经断开。
5、Send可能出现缓冲区满的情况
判断out出来的SocketError，如果等于SocketError.WouldBlock，则是Send缓冲区已满，应断开该Socket，否则影响整体速度，而不应当again,反过来说允许的错误码只有SocketError.Interrupted，此时可以重来一次。
6、主动断开Socket
MSDN说道:如果当前使用的是面向连接的 Socket，则必须先调用 Shutdown 方法，然后才能关闭 Socket。这可以确保在已连接的套接字关闭之前，已发送和接收该套接字上的所有数据。
所以，网络库的Close函数可以封装为先调用 Shutdown(SocketShutdown.Both)，在调用Close()。
7、Socket已经关闭(Close)但不能在另一端断开
一端Scoket已经关闭了，但另一端短时间内仍可以发送数据！这个问题还没有找到解决办法的，但原因已知，在《Windows网络编程技术》一书(P139-P140)中说道:被动关闭的情况下，应用程序会从对方那里接收一个FIN包，并用一个ACK包做出响应。此时，应用程序的套接字会变成ClOSE_WAIT状态。由于对方已关闭自己的套接字，所以不能再发送数据了。但应用程序却不同，它能一直发送数据，直到对方的套接字已关闭为止。

 

 

linux中send函数MSG_NOSIGNAL异常消息              

 

linux下当连接断开，还发数据的时候，不仅send()的返回值会有反映，而且还会向系统发送一个异常消息，如果不作处理，系统会出BrokePipe，程序会退出，这对于服务器提供稳定的服务将造成巨大的灾难。为此，send()函数的最后一个参数可以设MSG_NOSIGNAL，禁止send()函数向系统发送异常消息