server: vxworks 6.3 calls the usual socket, bind, listen, then: for (;;) { client = accept(sfd,NULL,NULL); // pass client to worker thread } client: .NET 2.0 TcpClient constructor to connect to server that takes the string hostname and int port, like: TcpClient client = new TcpClient(server_ip, port); This is working fine when the server is compiled and executed in windows (native c++). intermittently, the constructor to TcpClient will return the instance, without throwing any exception, but the accept call in vxWorks does not return with the client fd. tcpstatShow indicates no accept occurred. What could possibly make the TcpClient constructor (which calls 'Connect') return the instance, while the accept call on the server not return? It seems to be related to what the system is doing in the background - it seems more likely to get this symptom to occur when the server is busy persisting data to flash or an NFS share when the client attempts to connect, but can happen when it isn't also. I've tried adjusting priority of the thread running accept I've looked at the size of the queue in 'listen'. There's enough. The total number of file descriptors available should be enough (haven't validated this yet though, first thing in the morning)