mark_c wrote:In this version of the code, if I introduce a certain number of attempts when ByteReceived == 0, would it make sense?
No.
mark_c wrote:I thought that ByteReceived returns 0 if at that moment the buffer is perhaps full or the server is overloaded: could it be so?
No, that is not what it means. Where did you ever get that idea from?
When a read operation returns 0 bytes received, it means the peer gracefully closed its end of the connection. You need to stop and close your end of the connection. That is why in my earlier example, I 'break' the reading loop if the connection is closed before the HTTP header terminator ("\r\n\r\n") is reached.
mark_c wrote:code changes with the number of attempts
That change is not necessary, or correct. The ONLY condition that should ever need to do that kind of looping is when the read operation fails with a WSAEWOULDBLOCK error, but that cannot happen in blocking mode, so that loop makes no sense in this example.
mark_c wrote:I forgot to tell you that I am stubbornly continuing to use BCB6 32 bit version for historical reasons, I am fond of this development environment.
As am I. I still use BCB6 daily in my day job.
mark_c wrote:After this I ask you if there is a maximum number of sockets that can be opened simultaneously of the client type in windows.
On Windows, the number of active sockets is limited only by available memory, as sockets are treated as true kernel objects. Unlike on other platforms, where sockets use file descriptors and there is usually a limit on the number of open file descriptors.
Note that for client sockets, you can also be limited by the number of local ports that are available. It really depends on what destinations the clients are connected to. For example, if you have multiple clients connected to the same server IP/port, then you are limited to 65535 clients per network adapter, since ports are 16bit numbers, and socket connections are uniquely identified by a tuple of protocol, local IP/port, and remote IP/port, so the number of unique combinations available decreases when portions of those tuples are repeated by multiple connections.
mark_c wrote:Is there also a limit to the number of instantiable threads or is it just a matter of memory in this case?
Yes, the number of threads you can create is also limited only by available memory.
mark_c wrote:Currently without increasing the stack area, if I try to instantiate 2000 threads, an exception is generated after 1519 threads.
The default stack size is 1MB. So 2000 threads would easily reach the default 2GB limit for a 32bit process. To create more threads, you would have to decrease (not increase!) the stack size of each thread. But a 32bit process should NEVER need that many threads to begin with. That is a sign of poor code design. In this situation, using asynchronous socket I/O would come into play, either by using non-blocking sockets with multiplexing via the Winsock select() or WSAPoll() function, or using a small handful of threads with Win32 Overlapped I/O or I/O Completion Ports.