Hi RTT;
hehe, okay, you're right. :-)
Regards,
Markus Mueller
>> Correct, beside the maximum limit of 65,353 in detail: With TCP Window
>> Scaling (RFC 1323) you can use values up to two Gigabytes.
>>
> I read 1GB
>
> From RFC1323:
> "Since the max window is 2**S (where S is the scaling sh
> Correct, beside the maximum limit of 65,353 in detail: With TCP Window
> Scaling (RFC 1323) you can use values up to two Gigabytes.
I read 1GB
From RFC1323:
"Since the max window is 2**S (where S is the scaling shift count) times
at most 2**16 - 1 (the maximum unscaled window), the maximum w
Markus Mueller wrote:
> Correct, beside the maximum limit of 65,353 in detail: With TCP Window
> Scaling (RFC 1323) you can use values up to two Gigabytes. But, as
> I sayed, you have to enable This option via Tcp1323Opts. And both, the
> client as well as the server, must support this TCP option.
Hi Arno Garrels,
> Markus Mueller wrote:
>
>> The default is that it is not configured. Cause tcp window scaling is
>> also deactivated, I asume it uses the "normal" tcp maximum of 64
>> Kbyte.
>>
>> Without the "Tcp1323Opts" for Windows scaling a higher TCP Window
>> Size don't make sense at a
Markus Mueller wrote:
> The default is that it is not configured. Cause tcp window scaling is
> also deactivated, I asume it uses the "normal" tcp maximum of 64
> Kbyte.
>
> Without the "Tcp1323Opts" for Windows scaling a higher TCP Window
> Size don't make sense at all. For more informations see
The default is that it is not configured. Cause tcp window scaling is also
deactivated, I asume it uses the "normal" tcp maximum of 64 Kbyte.
Without the "Tcp1323Opts" for Windows scaling a higher TCP Window
Size don't make sense at all. For more informations see
http://proj.sunet.se/E2E/tcptune.
Yes I learned some things reading your thread. Anyway, just checked
with regedit and my Vista x64 registry has no such key. What is the
default value?
Regards,
SZ
On Sat, Jan 24, 2009 at 1:41 PM, Markus Mueller wrote:
> Hello ICS,
>
> I found the problem, it was
>
> HKEY_LOCAL_MACHINE\SYSTEM\Cu
Hello ICS,
I found the problem, it was
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize
set to 16 Mbyte on my Windows Systems.
Thanks for your support and your time! You have helped me very very much!
Much regards,
Markus Mueller
>> Hi RTT,
>>
>> which Operat
> Hi RTT,
>
> which Operationgsystem and Pachlevel are you using? Do you
> use ICS Version 6 RC1 ? I am using Windows XP with
> Service Pack3, tested my Client now on 3 Clients with this config.
> I am using ICS Versoin 6 at RC1. I added my client.exe and
> server.exe on my server http://projekte.
Markus Mueller wrote:
> Hi Arno Garrels,
>>> this is a bugreport that on localhost the windows kernel reads
>>> megabytes of data
>>> before a TWSocket client can block.
>>>
>>
>> This is not specific to TWSocket and it's not a bug but a winsock
>> feature!
>> Beside the fact that you should send
Francois PIETTE schrieb:
>> And there I am true that V6 ICS directly runs "send" on Winsock to
>> immediatlely send the data. And that was the point:
>> It not buffers internaly but forces to send
>> it immediately to winsock or it blocks.
>>
>
> I don't agree, unless a bug has been introduced
> Any idear why on my Computers it shows
> but on your computer it blocks much earlier?
Maybe be you some kind of proxy, firewall, anti-virus, anti-spam, malware,
LSP, VPN and other kind of similar piece of software intercepting TCP trafic
and buffering data somewhere.
--
francois.pie...@overby
> And there I am true that V6 ICS directly runs "send" on Winsock to
> immediatlely send the data. And that was the point:
> It not buffers internaly but forces to send
> it immediately to winsock or it blocks.
I don't agree, unless a bug has been introduced recently.
Send only TRIES to send data.
Markus Mueller wrote:
> I missed to tell that my sentence is only valid if you do
> "TWSocket.Flush;".
> And there I am true that V6 ICS directly runs "send" on Winsock to
> immediatlely
> send the data. And that was the point: It not buffers internaly but
> forces to send
> it immediately to wins
Hi Arno Garrels,
>> this is a bugreport that on localhost the windows kernel reads
>> megabytes of data
>> before a TWSocket client can block.
>>
>
> This is not specific to TWSocket and it's not a bug but a winsock
> feature!
> Beside the fact that you should send smaller data chunks and use
Markus Mueller wrote:
> Hello ICS Mailinglist,
>
> this is a bugreport that on localhost the windows kernel reads
> megabytes of data
> before a TWSocket client can block.
This is not specific to TWSocket and it's not a bug but a winsock
feature!
Beside the fact that you should send smaller data
Hi RTT,
which Operationgsystem and Pachlevel are you using? Do you
use ICS Version 6 RC1 ? I am using Windows XP with
Service Pack3, tested my Client now on 3 Clients with this config.
I am using ICS Versoin 6 at RC1. I added my client.exe and
server.exe on my server http://projekte.priv.de/ics_lo
Hi Francois Piette,
>> - By the way: If you have no Line Mode then ICS don't do
>> buffering at all. It just uses "send" of Winsock!
>>
> This sentence is wrong. TWSocket use a FIFO buffer when you call Send.
> Whatever data size you send, TWSocket will use a list of buffers (Each
> having a
I have not read all the discussions, but at least this:
>- By the way: If you have no Line Mode then ICS don't do
> buffering at all. It just uses "send" of Winsock!
This sentence is wrong. TWSocket use a FIFO buffer when you call Send.
Whatever data size you send, TWSocket will use a list of bu
> 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
>
>> - 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!
>>
> - 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 a
Hello!
> HI Piotr Dałek,
> yes you are right with your argumentation. I am using TWSocket in a manner
> generally not allowed, cause message processing and so on is not assured.
And we can stop right here.
Since I'm a ICS V5 user, I cannot answer to your "but"'s - maybe something
has changed in
HI Piotr Dałek,
yes you are right with your argumentation. I am using TWSocket in a manner
generally not allowed, cause message processing and so on is not assured.
BUT!
- 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
Hello!
> Hello ICS Mailinglist,
> this is a bugreport that on localhost the windows kernel reads megabytes
> of data
> before a TWSocket client can block. As you can see on the following
> explanation
> and the images on
> http://projekte.priv.de/ics_localhost_bug/
> , the problem is the wind
Hello ICS Mailinglist,
this is a bugreport that on localhost the windows kernel reads megabytes
of data
before a TWSocket client can block. As you can see on the following
explanation
and the images on
http://projekte.priv.de/ics_localhost_bug/
, the problem is the windows kernel:
"client_int
WOW! I have another prove for Buffering of Winsock! The used Memory is
NOT increasing
at alll! This means that the WINDOWS KERNEL is caching this!!!
>
>
>> Ok, this proves that Winsocks is buffering megabytes of data before
>> "TWSocket.pause" becomes active!
>>
>
> Not quite correct, TWSo
Markus Mueller wrote:
> Ok, this proves that Winsocks is buffering megabytes of data before
> "TWSocket.pause" becomes active!
Not quite correct, TWSocket.Pause becomes active immediately, however
winsock obviously continues to buffer incomming data, in this case I
think there's not much you ca
Hello Markus,
What is RAM usage then? How could Winsock buffer hundreds of MBs when you
don't read and flush the buffer? If it was correct, you should see process
RAM usage go up and up to the ceiling!!
Regards,
SZ
On Fri, Jan 23, 2009 at 7:52 PM, Markus Mueller wrote:
> Hello SZ,
>
> why the
Hello SZ,
why then the data comes through the WSocketGetProc('recv') function, in
WSocket_Synchronized_recv? This IS Winsock! And if I set a breakpoint
to this FRecv(s, Buf^, len, flags); then every thread running through this
function causes a stop on all threads!
Regards,
Markus Mueller
> AFAIK
AFAIK, Winsock buffers as much as only its buffer size data! It is ICS that
buffers data when you have paused it and when you press F8 on a breakpoint,
all threads run in the background.
HTH,
SZ
On Fri, Jan 23, 2009 at 7:41 PM, Markus Mueller wrote:
> Hello Arno Garrels and...
>
> Special Hell
Hello Arno Garrels and...
Special Hello to Francois Piette! Please look at the "@Francois Piette"
at the end of this mail!
>> This is exactly the point! I just don't get who reads the data, but
>> there is defintively
>> something reading all the available data (into a buffer?)!
>> Later I see
>>
Markus Mueller wrote:
> Hello (again :-)) Arno Garrels,
>>> I looked over the code of "THttpCli" and if you do not have a
>>> connection from localhost to localhost it may work... I expect this
>>> in particular cause the read of Megabytes is done within split
>>> seconds,
>>>
>> Yes, it is very f
Hello (again :-)) Arno Garrels,
>> I looked over the code of "THttpCli" and if you do not have a
>> connection from localhost to localhost it may work... I expect this
>> in particular cause the read of Megabytes is done within split
>> seconds,
>>
> Yes, it is very fast.
>
so you agree a
Markus Müller wrote:
> Hi Arno Garrels,
>
> I looked over the code of "THttpCli" and if you do not have a
> connection from localhost to localhost it may work... I expect this
> in particular cause the read of Megabytes is done within split
> seconds,
Yes, it is very fast.
> also if my program
Hi Arno Garrels,
I looked over the code of "THttpCli" and if you do not have a connection
from localhost to localhost it may work... I expect this in particular cause
the read of Megabytes is done within split seconds, also if my program is
sleeping (for example on a breakpoint in Delphi).
The pr
Markus Mueller wrote:
> it buffers sometime within 2-4 MByte before "socket.pause" does help,
> my
>> 3 Ghz Dualcore
> seems to buffer also hunderts of MByte...
procedure TCustomWSocket.Pause calls winsock API WSAAsyncSelect.
It simply tells winsock to stop posting notification messages.
"Altho
Sorry... I must correct myself again... The problem is still there, on
machine with 1,4 Ghz
it buffers sometime within 2-4 MByte before "socket.pause" does help, my
>3 Ghz Dualcore
seems to buffer also hunderts of MByte...
> Hello again
>
> I realy don't know why, but on a different machine
Hello again
I realy don't know why, but on a different machine there is this buffering
with unchanged source code NOT. Maybe its my virusscanner or something
like this... Sorry for any convenience
this may cause...
Regards,
Markus Mueller
> Hi ICS Mailinglist,
>
> I use the V6 Rev1 ICS TWSo
Hi ICS Mailinglist,
I use the V6 Rev1 ICS TWSocket and have a issue with buffering somewhere in
ICS and/or Winsock.
On localhost or in my local LAN, if I have there a stream to my ICS
Server which
just "pushes" data, like the DATA-TCP Connection of ftp, then all data
is sent just
in some second
40 matches
Mail list logo
