send

本篇我们用一个测试机上的阻塞socket实例来说明主题。文章中所有图都是在测试系统上现截取的。 需要理解的3个概念 1. TCP socket的buffer 每个TCP socket在内核中都有一个发送缓冲区和一个接收缓冲区，TCP的全双工的工作模式以及TCP的流量(拥塞)控制便是依赖于这两个独立的buffer以及buffer的填充状态。接收缓冲区把数据缓存入内核，应用进程一直没有调用recv()进行读取的话，此数据会一直缓存在相应socket的接收缓冲区内。再啰嗦一点，不管进程是否调用recv()读取socket，对端发来的数据都会经由内核接收并且缓存到socket的内核接收缓冲区之中。recv()所做的工作，就是把内核缓冲区中的数据拷贝到应用层用户的buffer里面，并返回，仅此而已。进程调用send()发送的数据的时候，最简单情况（也是一般情况），将数据拷贝进入socket的内核发送缓冲区之中，然后send便会在上层返回。换句话说，send（）返回之时，数据不一定会发送到对端去（和write写文件有点类似），send()仅仅是把应用层buffer的数据拷贝进socket的内核发送buffer中，发送是TCP的事情，和send其实没有太大关系。接收缓冲区被TCP用来缓存网络上来的数据，一直保存到应用进程读走为止。对于TCP，如果应用进程一直没有读取，接收缓冲区满了之后

Is there any reason for a blocking call to winsock's send() function on Vista to return immediately ? It works with expected delay on XP and below. I'm wondering if this has got anything to do with auto-tuning feature of Vista. Code: char *pBuffer; // pointer to data int bytes; // total size int i = 0, j=0; while (i < bytes) { j = send(m_sock, pBuffer+i, bytes-i, 0); i+=j; } Thanks, Pavan The first possibility is that send() failed and returned SOCKET_ERROR. Your code cannot detect this, you really ought to fix that. The next possibility is that send() just doesn't block. Which is pretty