optimax

Thanks for the link. I just added a comment to RSP-19708 with the details of the code for TSocket.Accept and TSocket.Select, showing the error in the implementation of TSocket.Accept and the correct implementation of TSocket.Select.

So, I found some interesting details, which all seem to point to a buggy implementation of TSocket.Accept when targeting Linux. Instead of LConnectionSocket := FServerSocket.Accept(500); if Assigned(LConnectionSocket) then begin ... I wrote the following code: LReadFds := TFDSet.Create(Self); LWaitResult := FServerSocket.Select(ReadFds, nil, nil, 500); if LWaitResult := TWaitResult.wrSignaled then begin LConnectionSocket := FServerSocket.Accept; if Assigned(LConnectionSocket) then begin Log('Daemon - New connection - ' + LConnectionSocket.RemoteAddress + ':' + IntToStr(LConnectionSocket.RemotePort)); LConnectionThread := TTCpConnectionThread.Create(LConnectionSocket); ... ... and it works, both when compiled for Windows and Linux ! The difference being that TSocket.Accept is now called without a parameter (infinite wait, but returns immediately because a client connection is pending), this pointed to the problematic implementation of TSocket.Accept with a timeout: if not (TSocketState.Listening in FState) then raise ESocketError.CreateRes(@sSocketNotListening); Result := nil; if Timeout <> INFINITE then begin FD_ZERO(FDR); _FD_SET(FSocket, FDR); time.tv_sec := Timeout div 1000; time.tv_usec := (Timeout mod 1000) * 1000; Res := socketselect(1, @FDR, nil, nil, @time); // << this is where things go wrong when compiled for Linux CheckSocketResult(Res, 'select'); if Res = 0 then Exit; end; Len := SizeOf(Addr); ClientHandle := acceptsocket(FSocket, Addr, Len); CheckSocketResult(ClientHandle, 'accept'); Result := GetClientSocket(ClientHandle, Addr); The problem is the call to socketselect(1, @FDR, nil, nil, @time). This code works fine in Windows because the first hardcoded parameter (nfds = 1) is ignored. However, in Linux, this parameter must be the set to the highest-numbered file descriptor in any of the three sets + 1. So for Linux, this implementation is telling socketselect() to only look at file descriptor 0, which is almost certainly not what the socket is set to. This is however correctly implemented in TSocket.Select (I am not sure why TSocket.Accept does not simply call TSocket.Select, rather than re-implementing the same functionality at low level): ReadFds := GetFds(CheckRead); WriteFds := GetFds(CheckWrite); ErrorFds := GetFds(CheckError); if Microseconds >= 0 then begin time.tv_sec := Microseconds div 1000000; time.tv_usec := Microseconds mod 1000000; TimePtr := @time; end else TimePtr := nil; Res := socketselect(Max(GetMaxFds(CheckRead), Max(GetMaxFds(CheckWrite), GetMaxFds(CheckError))) + 1, ReadFds, WriteFds, ErrorFds, PTimeVal(TimePtr)); CheckSocketResult(Res, 'select'); if Res = 0 then Result := TWaitResult.wrTimeout else Result := TWaitResult.wrSignaled; More information about the low level call to select() can be found here: https://stackoverflow.com/questions/2008059/socket-select-works-in-windows-and-times-out-in-linux I guess the next step is to report this as a bug to Embarcadero...

Hi, I have a Tcp daemon thread using TSocket from System.Net.Socket (cross platform), listening for incoming TCP connection and creating client threads when clients connect. It works just fine when compiled and run under Windows. I can connect with a Windows TCP client, a Linux TCP client, or even a simple Linux telnet session, and handle the client communication in the client thread. When compiled and run under Linux, it seems that TSocket.Accept always returns nil, even when a connection is successfully established via telnet or other client. Hence the code that creates the client threads is never executed.... In Linux, my logs show an infinite series of 'Daemon - Socket.Accept with timeout 500ms' followed by 'Daemon - No new connection after 500ms timeout', although a connection can be successfully established. However, without a client thread and a reference to the client socket, there isn't much I can do to handle the client communication... Has anyone seen this behavior when compiling a TCP server for Linux based on System.Net.Socket ? Any hint or help would be very much appreciated. procedure TTcpDaemon.Execute; var LConnectionSocket: TSocket; LConnectionThread: TTcpConnectionThread; begin FServerSocket := TSocket.Create(TSocketType.TCP, TEncoding.UTF8); FServerSocket.Listen(FIP, '', FPort); Log('Dameon started (IP: ' + FIP + ' Port: ' + IntToStr(FPort) + ')'); Log('Daemon - ConnectionThreadCount: ' + IntToStr(GetConnectionThreadCount)); while not Terminated do begin try Log('Daemon - Socket.Accept with timeout 500ms'); LConnectionSocket := FServerSocket.Accept(500); if Assigned(LConnectionSocket) then begin Log('Daemon - New connection - ' + LConnectionSocket.RemoteAddress + ':' + IntToStr(LConnectionSocket.RemotePort)); LConnectionThread := TTcpConnectionThread.Create(LConnectionSocket); FThreadList.Add(LConnectionThread); Log('Daemon - Adding new connection thread - ConnectionThreadCount: ' + IntToStr(GetConnectionThreadCount)); Log('Daemon - Starting new connection thread'); LConnectionThread.Start; end else Log('Daemon - No new connection after 500ms timeout'); except on E: Exception do Log(Self.ClassName + ' Exception (' + E.ClassName + '): ' + E.Message); end; end; TerminateAllThreads; FServerSocket.Close(True); end;