我们用的开发平台是基于linux 2.4 内核代码上的，上层的应用程序都是通过socket进行通信的（包括进程间通信和网络通信），socket都设置位nonblock，但是最近经过测试发现有两种情况下socket的系统调用会一直阻塞不能返回： 1，select的调用，这种情况下的socket是作为服务端，且已经建立了连接，我们对select设置了超时时间，但有时候可能是由于调用select太频繁（服务端向客户端发送大数据，服务端把大数据分片发送，select就是等...

如果l_onoff =1,l_linger=1，close socket后，是不是应用程序立即返回，而内核仍然在继续发送socket里的残余数据。

非阻塞socket 定时connect 一台机器，如果对端不应答的话，第一次连接是syn_send状态，第二次连接时，connect会返回什么错误号？

unix的是不是一定要在使用socket之前才能设置它是否为阻塞?

我用下面的语句读socket数据 while ($buffer) { $buffer = undef; recv(socket,$buffer,256,0); $receive .= $buffer; } 读了几次数据后，数据传完了时执行到recv(socket,$buffer,256,0);就阻塞了，不往下了。我想知道怎么去判断数据已经传完了应该往下执行了呢？我看了帮助，好象跟socket的阻塞与否有关，要用什么fcntl函数，不过不知道跟这有什么关系。

我用阻塞模式的套接字,为什么连接上以后,就算对方不发送数据recv函数也不会阻塞呢? 和我在局域网里作实验速度快有什么关系吗? 或者是不是系统内部有一个时钟,阻塞了一定时间会停止阻塞呢?

如果l_onoff =1,l_linger=1，close socket后，是不是应用程序立即返回，而内核仍然在继续发送socket里的残余数据。

socket编程中，有时会需要这样一种情况：服务器不断的向输出流中输出数据，客户端不断的读取数据。同时，只要客户端的输入流中有可读的数据，立即读取，如果没有，则阻塞等待。 但是客户端的输入流不可能保证在它想读数据的时候就一定会有可读的数据，如果直接去读的话就会抛出异常，为了避免这种情况的发生，一般的做法是在读取数据前先检查输入流中是否有可读数据：有，读取；没有，等待。就像下面的一样，这里省去服务器部分，强...

对一个非阻塞的socket(tcp ，ipv4) 调用close 不是会直接导致发送RST而不是FIN？ 我试验了下是这样的哦 没有看到FIN了 SO_LINGER设置没有问题的 SO_LINGER: default = l_onoff = 0, l_linger = 0

各位前辈，我用 [code] Selector selector = null; try { // Create the selector selector = Selector.open(); socketChannel sChannel1 = createsocketChannel("hostname.com", 80); sChannel1.register(selector, sChannel1.validOps()); } catch (IOException e) { } while (true) { try { selector.select(1000); } catch (IOException e)...