Hi, thanks for for quick response.
ad 1: I see, this has been a classical problem in my mind
I interpreted the remove as belonging to the list, not to the TTCPServer class - shame on me.
ad 2: I think I will try the second suggestion. This should also simplify the TClientThread's execute method and I can use an event for resuming the "TSendClientThread"'s when data is available for sending.
Is it possible without causing trouble to use a separate TBlockSocket for the sending thread? I'm asking because both the receiving and the sending thread will have to use the same ports. I don't want the clients themselves to require two threads too because this would cause incompatibilities with other tools (in my case, especially telnet-Clients must be able to connect for debugging purposes).
It might also be possible that #2 is just a misuse of your component on my side. I'm using the TTCPServer's instance's SendMessage method for responding. I'm not sure whether this is correct. In my app, I have to separate the server logic from the protocol logic. All examples I have found for servers using TBlockSocket (e.g. a chat server somewhere else in this forum) do the response directly inside the client's Execute method. Of course, this is done for simplicity of the example, and indeed this makes creating a TCP server very simple, but I feel that things quickly get rather complicate when decoupling response handling from the server and taking into account that it might take a moment to prepare the response while everything should keep responsible in the meantime and no packets must get lost.
Overall, your server is very well designed and I hope it will work threadsafe even for a greater number of clients. I always have a some trouble in getting multithreading right, so your example has been of great value for me.