>> - 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 
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 
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?

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

Reply via email to