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

VIM显示十六进制出错

在linux下用vim打开jpg文件，使用％！xxd进行16进制显示时，文件头显示为"3f3f
3f3f 0011 0804"文件尾端显示为 "3f3f
0a"；而同样的操作在windows下，就显示为"ffd8 ffc0 0011 0804"和 "ffd9
0a"，这才是正确的jpeg文件头和文件尾标志。
很蹊跷 !
初时，我以为是jpeg在windows和linux下是不同的文件头，后来把jpg后缀去掉，就一个纯文件，现象依旧。考虑可能不是操作系统的差异了。
重新使用ghex打开jpeg数据查看，发现显示正常，为"ffd8 ffc0 0011
0804"和 "ffd9 0a"，正确。
估计应该是vim的问题了。
3f的ascii码是？，那表示vim对文件头、尾没有正常解析，是不是和vim解析文件时用的编码格式有关系呢？
打开.vimrc配置项，屏蔽掉下面这句话：
set fileencodings=utf-8,gb2312,gbk,gb18030,ucs-bom
再用vim打开jpeg文件，显示"ffd8 ffc0 0011 0804"和 "ffd9 0a"，
显示正确。
原来，为了支持识别和显示中文，我规定了vim的fileencodings,
当vim打开文件时，会使用规定的编码格式对数据进行解析，可惜jpeg的文件头FFD8、尾FFD9
不是任何一个中文的编码，vim找不到对应的中文字，就显示为？？，即：3f3f。
至此，困惑全部打开。