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 fast. >> > so you agree a (at least 1000ms) timer can't help on localhost if it > is done in > very less ms?
Yes, there are probably better solutions that using a timer for localhost connections. > > I am going to try and write an response to the mailing ist if I can > produced the problem with the THttpClient Object. I am also going to > write a simple sample TWSocket Daemon which just tries to read only a > fixed number of bytes. In my theory thats impossible and I'll post > this in case as an > bug report > (to this maling list?). You should upload it to some webserver and post the link here, The list doesn't allow larger attachments. >>> also if my program is sleeping (for example on a breakpoint >>> in Delphi). >>> >> How do you manage this? If the application stops at a breakpoint >> it can no longer receive data. >> > 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 > the data flowing > through the "WSocket_Synchronized_recv": So I think it can only be > Winsock who > is buffering, cause the actual data reading call is "FRecv" which is a > Winsock function! > Am I right at this? Yes, that's correct. > > For your information: I have beside the GUI two threads: One server > and > one client > thread. Hmmm... Delphi does stop all threads if I am at a breakpoint, > doesn't it? Yes, correct. >>> The problem is that the read occures within miliseconds because >>> localhost does >>> not have any latency. In the case of THttpCli ther there is a 1000ms >>> timer: I think >>> this is much too slow to prevent the reading of so many data >>> (Megabytes!) within >>> this small time, isn't it? >>> >> Yes, that's why THttpCli has a property BandwidthSampling which sets >> the timer interval. >> > I use the "wsoNoReceiveLoop" Flag, but this problem also occures with > this flat. > > I run the "pause" in OnDataAvailable in the case that I read too much > data. I programmed > (for debugging) a fixed size I only want to read: If I read (in 4096 > bytes chunks) > over this value then I run "TWSocket.pause". But this don't work! I > don't get further > OnDataAvailable (with "wsoNoReceiveLoop" Flag), but the data has been > read from > the FTP Client at all! Do you use LineMode? I do not think so but should be asked anyway. If LineMode is turned on the component indeed buffers data internally. > > I had one idear about this "wsoNoReceiveLoop"-Flag in Source Code on > the FD_CLOSE > handler: It removes the flag and reads all available data cause it > maybe > is impossible later... > I changed here that "wsoNoReceiveLoop" is not removed, so it should > NOT read all the > data. But also this don't change anything! >>> In my Client ICS Proxy software I have my own Message Loop, I don't >>> juse socket.MessageLoop but process the messages in .Execute of my >>> Thread by myself. If the problem would be the messages, then I would >>> be able to ignore them there... But the read is done if my Client >>> sleeps (for example on a breakpoint) or not! So I think the messages >>> are not the problem... >>> >> That's correct, a little bit later, after I wrote my previous >> replay, I recalled that after Pause a flag is set internaly and the >> component ignores those notification messages still waiting in the >> application message queue when this flag is set. >> > Where is the problem then? Do you have any idear who could it be who > reads all the data? Or are you realy shure that this MUST be the > AsyncRead Function? Hmm, should you realy use LineMode the set a breakpoint in (OverbyteIcs) WSocket.pas: function TCustomLineWSocket.TriggerDataAvailable(ErrCode : Word) : Boolean; At the line where Receive is called. If you do not use LineMode winsock is most likely the reason. Or maybe you have you increased the default Socket receive buffer size, property SocketRcvBufSize? -- Arno Garrels -- 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
