[twsocket] Test - Please ignore
Test - Please ignore -- 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
Re: [twsocket] Pause and Resume just not working!
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. Although WSAAsyncSelect immediately disables event message posting for the socket in this instance, it is possible that messages could be waiting in the application message queue. Therefore, the application must be prepared to receive network event messages even after cancellation. That's most likely what you observe, isn't it? BTW: The THttpCli component supports bandwidth control, search for UseBandwidthControl. -- 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
Re: [twsocket] Pause and Resume just not working!
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 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? 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... Maybe it is a general Winsock problem about Async read? Is it possible to put a Socket into a Sync read? Thanks in advance for any hints... I am completely frustrated about this problem... I just wanted to implement Flowcontrol into my Application, which I have developed over a month... And now I must search for a completely new network framework and must begin from root? :-( Much regards, Markus Mueller 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. Although WSAAsyncSelect immediately disables event message posting for the socket in this instance, it is possible that messages could be waiting in the application message queue. Therefore, the application must be prepared to receive network event messages even after cancellation. That's most likely what you observe, isn't it? BTW: The THttpCli component supports bandwidth control, search for UseBandwidthControl. -- 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
Re: [twsocket] Pause and Resume just not working!
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 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. 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. 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. Maybe it is a general Winsock problem about Async read? I don't think so, the component only reads from the socket when it gets a notification message. Is it possible to put a Socket into a Sync read? Possible yes ( with winsock API ), however I would not recomment doing that. Have you tried option wsoNoReceiveLoop yet? -- Arno Garrels Thanks in advance for any hints... I am completely frustrated about this problem... I just wanted to implement Flowcontrol into my Application, which I have developed over a month... And now I must search for a completely new network framework and must begin from root? :-( Much regards, Markus Mueller 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. Although WSAAsyncSelect immediately disables event message posting for the socket in this instance, it is possible that messages could be waiting in the application message queue. Therefore, the application must be prepared to receive network event messages even after cancellation. That's most likely what you observe, isn't it? BTW: The THttpCli component supports bandwidth control, search for UseBandwidthControl. -- 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
Re: [twsocket] Pause and Resume just not working!
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? 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?). 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? 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? 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! 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? I also set a breakpoint to the DoRecv in the AsyncRead Function: Delphi never halts on this call... I investigated and found out that this is caused that by not using LineMode: It seems not to need to read here at all. So where else could the read have beeen done? Who reads the data if it is not AsyncRead? Maybe it is a general Winsock problem about Async read? I don't think so, the component only reads from the socket when it gets a notification message. There is realy nobody else than ICS who could buffere the data, isn't it? I think the problem points still to Winsocks... Is it possible to put a Socket into a Sync read? Possible yes ( with winsock API ), however I would not recomment doing that. Have you tried option wsoNoReceiveLoop yet? Yes, sure, I found the option by investigating the cause in the source. But for me it doesn't change anything beside that I don't get OnDataAvailable many times without data after I got one or more OnDataAvailable Events with readable data. Thank you very much for your help! If you need you get payed for your help please tell me. There is a budget for this! 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
Re: [twsocket] Pause and Resume just not working!
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
Re: [twsocket] Pause and Resume just not working!
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 can do and that won't be related to async sockets IMO. TWSocket.Pause just stops winsock event notification. 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 am not using LineMode. If you look at TriggerDataAvailable you'll see that it never gaves the DoRecv in AsyncReceive a change to read. So I think it is proved that the problem is in Winsock, do you also think so? I doubt that it was a problem at all. Winsock does a lot of things in the background you cannot control, even when the socket handle is already closed. -- 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
Re: [twsocket] Pause and Resume just not working!
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 windows kernel: No. The problem is that you don't understand how ICS work. By this: transfered := socket.Send(@buf, sizeof(buf)); assuming buf: array[0..102400] of byte; you command ICS TWsocket to send 102401 bytes. It doesn't necessarily mean that it goes straight to Windows Sockets (or TCP/IP stack, whatever). Now, in TWSocket.Send, component splits your data (these 102401 bytes) into ~1,5 kilobyte chunks, puts every chunk into FIFO (first-in-first-out) queue, enlarging it, then sends every chunk one-by-one, shrinking the queue. Component sends data to TCP/IP stack as long as this doesn't err out (ie. send() doesn't return error Operation would block - or any other error - what may happen when, for example, destination socket doesn't consume sent data). When you do .pause on receiving (*NOT* sending) socket, you say ok, now I don't want to know that new data have arrived. Meanwhile, sending TWSocket component *still* send data to TCP/IP on his side, TCP/IP sends data to destination socket, TCP/IP on the destination side sees that socket doesn't consume data so it buffers them as long as there's enough space for this (see SO_RCVBUF), and when buffer is full, it responds to sending side with some kind of sorry, i cannot handle more data, you're talking too fast. Sending socket, seeing this, responds to queue pumping code (within TWSocket) with Operation Would Block, what makes FIFO in TWSocket stop shrinking. That's why memory usage of sending application skyrockets: receiving side doesn't receive data (because it doesn't want to know that data have arrived), and sending side is not aware of this. Why? Because you just say send! send! send! send it goddamnit! send it!!! not checking whether something has actually been sent *and* received. You have OnDataSent for this purpose - it's fired when TWSocket sending FIFO queue is emptied successfully. To cut things short - by using TWSocket's send method, you say put these data in your buffers, send it to the other side, and tell me, by firing OnDataSent, when you've dealt with that.. If you use send again - before having received OnDataSent event - you say hey, I have some more data to send, send them when you'll deal with all previous data, and tell me, by firing OnDataSent, when you'll send *all* data - the previously ordered to send *and* the new data. HTH. -- Piotr Dałek enigmati...@interia.pl -- Kochanka - kobieta drugiej kategorii? sprawdz http://link.interia.pl/f2026 -- 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
Re: [twsocket] Pause and Resume just not working!
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 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 tried now with Putty, which is an SSH Client able to provide TCP Tunnels on localhost. I forwarded it to a Socket not accepting any data. If I run my Client from localhost to the opened port on localhost from Putty, I have the same 16 MBytes of caching! And also there is only 3 MBs of RAM used by the client. - The same problem is with Mails sending via Thunderbird: I get a timeout if I send a big mail via an SSH Tunnel cause the Data is immediatley in the big buffer but the real Transfer via Putty consumes much more time. So the Thunderbird throws an error. - By the way: If you have no Line Mode then ICS don't do buffering at all. It just uses send of Winsock! Because of this if at connecting to the linux host it immediatlely blocks, as shown in the screenshot. I hope you agree with me that my programming was not perfect but anyway proves the problem with TCP Read bufering on localhost on Windows. Do you agree? Regards, Markus Mueller 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 windows kernel: No. The problem is that you don't understand how ICS work. By this: transfered := socket.Send(@buf, sizeof(buf)); assuming buf: array[0..102400] of byte; you command ICS TWsocket to send 102401 bytes. It doesn't necessarily mean that it goes straight to Windows Sockets (or TCP/IP stack, whatever). Now, in TWSocket.Send, component splits your data (these 102401 bytes) into ~1,5 kilobyte chunks, puts every chunk into FIFO (first-in-first-out) queue, enlarging it, then sends every chunk one-by-one, shrinking the queue. Component sends data to TCP/IP stack as long as this doesn't err out (ie. send() doesn't return error Operation would block - or any other error - what may happen when, for example, destination socket doesn't consume sent data). When you do .pause on receiving (*NOT* sending) socket, you say ok, now I don't want to know that new data have arrived. Meanwhile, sending TWSocket component *still* send data to TCP/IP on his side, TCP/IP sends data to destination socket, TCP/IP on the destination side sees that socket doesn't consume data so it buffers them as long as there's enough space for this (see SO_RCVBUF), and when buffer is full, it responds to sending side with some kind of sorry, i cannot handle more data, you're talking too fast. Sending socket, seeing this, responds to queue pumping code (within TWSocket) with Operation Would Block, what makes FIFO in TWSocket stop shrinking. That's why memory usage of sending application skyrockets: receiving side doesn't receive data (because it doesn't want to know that data have arrived), and sending side is not aware of this. Why? Because you just say send! send! send! send it goddamnit! send it!!! not checking whether something has actually been sent *and* received. You have OnDataSent for this purpose - it's fired when TWSocket sending FIFO queue is emptied successfully. To cut things short - by using TWSocket's send method, you say put these data in your buffers, send it to the other side, and tell me, by firing OnDataSent, when you've dealt with that.. If you use send again - before having received OnDataSent event - you say hey, I have some more data to send, send them when you'll deal with all previous data, and tell me, by firing OnDataSent, when you'll send *all* data - the previously ordered to send *and* the new data. HTH. -- 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
Re: [twsocket] Pause and Resume just not working!
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 ICS V6, but anyway don't expect any predictible behavior when you're not using things right. -- Piotr Dałek enigmati...@interia.pl -- Sprawdz, co wyswietlaja kina w Twoim miescie! http://link.interia.pl/f2028 -- 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
Re: [twsocket] Pause and Resume just not working!
- 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. RTT -- 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
[twsocket] Bad link to TWSocket mailing list sign up page (ICS)
PREFACE: The link on the certain pages on the Overbyte.be and nearly every archived TWSocket mailing list message that is supposed to take you to the mailing list sign up form is wrong: Look at the FAQ page: http://users.telenet.be/sonal.nv/ics/faq/Frame_index.html Which has this link which leads to a 404: http://www.elists.org/mailman/listinfo/twsocket This is the correct link to the mailing list sign up page: http://lists.elists.org/mailman/listinfo/twsocket Perhaps you can get elists.org to set up a redirect? There's thousands of archived messages with the bad link which turn up when a user searches the Web. Thanks, Robert -- 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
Re: [twsocket] Pause and Resume just not working!
- 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
[twsocket] HTTP Post hanging during Basic authorization phase (2nd phase)
I am using Delphi Professional 6.0 pack 2 with ICS. I'm not sure what version of ICS I am using since I don't see the version number in the README. However, I checked HttPProt.pas and the final comment reads: Oct 15, 2004 V1.71 lotauro.mauri...@dnet.it enhanced basic and NTLM authentifications methods. Event OnNTLMAuthStep has been removed. I am trying to access a server that requires Basic Authentication. I can access the server without problem using FireFox. When I try it with THttpCli it hangs on the second attempt after it sends the request with the proper Authentication header line. I matched the Header data up as best as I could between what FireFox is sending and with what THttpCli sends during a Post attempt. I captured the Header and Data send and receive events and the Headers appear to be identical where it counts (Authorization, Content-Type, Accept, etc.). Note, I configured the Headers using the THttpCli properties, not by modifying the data in the OnCommand event (UserName, Password, Accept, ContentTypePost, etc.). I logged the transaction and I can see that THttpCli handles the initial 401 error, closes and reopens the connection, and makes the second attempt with the correct Authorization line in the Header data. I matched the encoded UserName/Password to the FireFox session and they are identical. However, after the request is sent with the Authorization data, THttpCli just hangs waiting for something until I Abort the connection. Does anyone know what is going wrong here or what I can try to debug it? I have included the log I captured during the THttpCli Post session. I have removed the encoded UserName/Password and added comments where I thought it might help. Thanks, Robert --- RESPONSE LOG Retrieving URL. HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Session connected. HttpCli1: Socket state change: Invalid state HttpCli1: Request Header begins. HttpCli1: Before Header send.! HttpCli1: Command: POST /rev.cgi HTTP/1.0 HttpCli1: Command: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HttpCli1: Command: Content-Type: application/xml; charset=UTF-8 HttpCli1: Command: User-Agent: Mozilla/4.0 (compatible; ICS) HttpCli1: Command: Host: 127.0.0.1 HttpCli1: Command: Pragma: no-cache HttpCli1: Command: Content-Length: 26 HttpCli1: Request header ends. HttpCli1: Command: HttpCli1: Send begins. HttpCli1: Send data event, length: 26 HttpCli1: Send ends. // I DO NOT GET PAST THIS POINT DURING THE AUTHORIZATION ATTEMPT. HttpCli1: Header begins. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header Data. HttpCli1: Header ends. HttpCli1: Socket state change: Invalid state HttpCli1: Header ends. HttpCli1: Document begins. HttpCli1: Doc data event, length: 173 HttpCli1: Document ended. HttpCli1: Session closed. // AUTHORIZATION ATTEMPT HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Socket state change: Invalid state HttpCli1: Session connected. HttpCli1: Socket state change: Invalid state HttpCli1: Request Header begins. HttpCli1: Before Header send.! HttpCli1: Command: POST /rev.cgi HTTP/1.0 HttpCli1: Command: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HttpCli1: Command: Content-Type: application/xml; charset=UTF-8 HttpCli1: Command: User-Agent: Mozilla/4.0 (compatible; ICS) HttpCli1: Command: Host: 127.0.0.1 HttpCli1: Command: Pragma: no-cache HttpCli1: Command: Content-Length: 26 HttpCli1: Command: Authorization: Basic (encoded login details removed by me for privacy reasons but it matches the FireFox session) HttpCli1: Request header ends. HttpCli1: Command: HttpCli1: Send begins. HttpCli1: Send ends. // THttpCli HANGS HERE. // END RESPONSE LOG --- -- 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
Re: [twsocket] Pause and Resume just not working!
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. Tested right now, and in my case it blocks normally at socket.Flush line since first cycle, no 'Sent # Bytes!' message show, so something is different at your system. RTT -- 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
Re: [twsocket] HTTP Post hanging during Basic authorization phase (2nd phase)
Scrive robertoschler robertosch...@yahoo.com: I am using Delphi Professional 6.0 pack 2 with ICS. I'm not sure what version of ICS I am using since I don't see the version number in the README. However, I checked HttPProt.pas and the final comment reads: Oct 15, 2004 V1.71 lotauro.mauri...@dnet.it enhanced basic and NTLM authentifications methods. Event OnNTLMAuthStep has been removed. This version has some problem with authentication that was corrected in later versions. I suggest to upgrade to a more recent one. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- 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
Re: [twsocket] HTTP Post hanging during Basic authorization phase (2nd phase)
Thanks Maurizio. That did the trick, it works now. Fortunately the new ICS (Version 5) hasn't affected anything in the current project, but I do have older projects that I made modifications to the ICS code which I will have to recode. That's why I hesitated at first to upgrade. Robert. --- On Fri, 1/23/09, Maurizio Lotauro lotauro.mauri...@dnet.it wrote: From: Maurizio Lotauro lotauro.mauri...@dnet.it Subject: Re: [twsocket] HTTP Post hanging during Basic authorization phase (2nd phase) To: ICS support mailing twsocket@elists.org Date: Friday, January 23, 2009, 7:12 PM Scrive robertoschler robertosch...@yahoo.com: I am using Delphi Professional 6.0 pack 2 with ICS. I'm not sure what version of ICS I am using since I don't see the version number in the README. However, I checked HttPProt.pas and the final comment reads: Oct 15, 2004 V1.71 lotauro.mauri...@dnet.it enhanced basic and NTLM authentifications methods. Event OnNTLMAuthStep has been removed. This version has some problem with authentication that was corrected in later versions. I suggest to upgrade to a more recent one. Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- 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 -- 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
Re: [twsocket] Pause and Resume just not working!
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 buffers (Each having a BufSize length wich by default is the largest data packet accepted on Ethernet so that fragmentation is the least possible). Each time you cann Send, TWSocket tries to deliver data from his FIFO to winsock. Each time winsock notifies that he has room into his own buffer, then TWSocket extract data from his FIFO and give it to winsock. Eventually, TWSocket empty his buffer and then triggers OnDataSent event. Winsock has his own buffers, usually 8KB for send and another 8KB for read. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- 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
