> >> - The clients wrote via "send" to somewhere about 16 Mbytes and if you >> were true and it would be in buffer of the client then the process would >> must have in Taskmanagers at least 16 MB of memory size. Please >> look at my screenshot, the server and the client does have just 3.5 MB! >> > I'm not an expert but I think you don't see the memory usage because > data is not cached in the client. Piotr clearly say that if the RCV > client is not accepting data, Winsocks cache it until its internal > buffer is full and only then report can't accept more because client is > too slow consuming it. > If you reproduce my test, simply by compiling and starting server.pas and then compiling and starting client.pas with attached delphi debugger, looking on code line executed step, you can see that "socket.flush" forces to write out the data via the "send" call of winsock before it proceeds. Of course not only on Version 6 of ICS but also on any other Framework or TCP/IP Server listening on localhost.
It is impossible that ICS is buffering here, because Winsock is a DLL from Microsoft not from ICS. But also the Winsock DLL can not be the one who is buffering, because the Winsock DLL also is running in userland and must be accounted on Taskmanager on the running process. The only thing not beeing accounted in Taskmanager memory is kernel memory allocated internal for one or more processes. And it makes sense, on localhost you can buffer much more than on network so I simply think Microsoft implemented this to increase performance on localhost connections. This is also traceable by Putty: Here is the same effect about buffering (see my last email about this) with Thunderbird sending a big email. What can I else do to prove that the kernel (on loopback connections) is the causer? Regards, Markus Mueller -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
