[twsocket] How to set in GSSLEAY_DLL_Name under BCB2010?
Hello, GSSLEAY_DLL_Name = SSLEAY32.DLL; doesn't seem to work! Regards, SZ -- 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] udp packet loss
Hi Francois, hi all I cannot reproduce the packet loss on localhost. Strange. I always lose some packets on localhost (at least setting Interval=0 on the client). I can reproduce on different computers, but I found a flaw in your design: remember TWSocket use non blocking. SendTo will fail if winsock is not able to receive data and you don't check that condition. Yes you're right. Now I've modified the code like this: procedure TForm1.OnTimer(aSender:TObject); begin if fWS.State=wsConnected then begin move(fCounter,fData^,4); if (fWS.SendTo(fPeerSrc,fPeerSrcLen,fData,fDataSize)0)or (WSocket_WSAGetLastError=WSAEWOULDBLOCK) then inc(fSent); end; end; procedure TForm1.WSocketDataSent(Sender: TObject; ErrCode: Word); begin if fSent0 then begin dec(fSent); inc(fCounter); inc(fBR,fDataSize); Restart; end; end; Is it right? This is like I do in my real application. I'm not sure you correctly checked with wireshark that all packets where sent actually because their aren't when SendTo fails. I'm pretty sure yes. I've set internal packet number equal to wireshark packet number. Inside wireshark, if I select one lost packet by the server application, I can see that internal packet number corresponds. So I think that this client side bug is not the cause of packet loss. However I've fixed it. Yesterday I have done some tests. I've tried different computers. I noticed that: On localhost I can reach very different max bitrates. From about 90Mbps under winXp (cpu=T2300@1.66GHz), until 250Mbps under win7 (cpu=I72630QM@2.00GHz), but always some packet are lost. On different machines, connected with a cross cable and Gbps ethernet cards (I've installed the udp server over Q9300 2,5GHz machine, using different operating systems), max bitrate is always about 160Mbps but: under winXp a lot of packets are lost. under win7 less packets are lost than using winXp. under ubuntu+wine less packets are lost than using winXp and about the same as win7. If I open wireshark many more packets are lost by the application (not by wireshark). I noticed that if I set: SetPriorityClass (GetCurrentProcess, HIGH_PRIORITY_CLASS); and fUDPServer.Priority:=tpNormal less packets are lost (no improvement if I set also fUDPServer.Priority:=tpTimeCritical); I've tried to compile a third party example of udp server that use winsock in a different way: http://www.tenouk.com/Winsock/Winsock2example9.html under windows and under linux, but the results are like the same. I've also tried Indy project, but no improvement has been obtained. I don't know if my tests are completely correct, but my conclusion is that the mechanism of messaging notification used by windows can create a udp rx bottleneck in some circumstances (system wide and not only application wide). In my real application (where bitrates are two orders of magnitude lower) I've create a thread pool to manage incoming and outcoming data. Data are transferred by threads using async queues (that use win messages) with skip data mechanism where possible. The result is that, however, udp rx is very (too much) sensible to any action done on the system. Now I'm working to reduce this sensibility. I can accept any other kind of compromise, but I'd like that if udp packets phisically arrive on the machine they were not discarded. var lBuffer:array[0..1500] of AnsiChar; I'd advice you not to allocate static buffer inside a method because it is placed inside the stack every time method is called. yes you're right. In my real application buffers are statically allocated. I'm going to modify also the example like you say. Thankyou for help, Emanuele -- 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] HttpNoBasicAuth
it's time for a rewrite from scratch IMO. And give it a different name, to bypass the no brake early code rule, or some of the annoyances will have to remain. Or start a new branch of renewed components. And, IMHO, if technically possible, the THttpCli should mix HTTP and HTTPS, and handle internally what protocol to use, based in the current URL, that can originate from an usual HTTP to HTTPS redirect. In my opinion, the future cross platform Delphi which will come sooner or later (hopefully sooner) will be the best candidate for a rewrite. It will be ICS V8. Given the fact that even the basic function (GetASync) is broken and hard to correct IMHO waiting for a next version of delphi is to late to start ( planning ) a rewrite. -- 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] FTP proxy always passive mode?
Hi, the TFtpClient always sets passive mode internally with native FTP-proxy connections, this is not correct IMO. OpenBSD ftp-proxy claims to support active and passive: https://calomel.org/ftp_proxy.html Also Filezilla client enforces PASV only with SOCKS and HTTP tunnel. -- Atno 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] HttpNoBasicAuth
- Original Message - From: Frans van Daalen i...@hedaal.nl To: ICS support mailing twsocket@elists.org Sent: Tuesday, March 01, 2011 10:22 AM Subject: Re: [twsocket] HttpNoBasicAuth it's time for a rewrite from scratch IMO. And give it a different name, to bypass the no brake early code rule, or some of the annoyances will have to remain. Or start a new branch of renewed components. And, IMHO, if technically possible, the THttpCli should mix HTTP and HTTPS, and handle internally what protocol to use, based in the current URL, that can originate from an usual HTTP to HTTPS redirect. In my opinion, the future cross platform Delphi which will come sooner or later (hopefully sooner) will be the best candidate for a rewrite. It will be ICS V8. Given the fact that even the basic function (GetASync) is broken and hard to correct IMHO waiting for a next version of delphi is to late to start ( planning ) a rewrite. During my tests last week it did not trigger OnRequestDone on relocations with StatusCode = 0 any more and that worked thru a proxy as well with different types of authentication. www.microsoft.de is good for testing relocations (3 or 4) and you should setup a proxy for testing as well, Squid for Windows seems to work quite well with basic, ntlm and digest, however with NTLM it reqiures a user code in the form of domain\username -- 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 -- 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] HttpNoBasicAuth
On Tue, Mar 1, 2011 at 12:43 PM, Arno Garrels arno.garr...@gmx.de wrote: - Original Message - From: Frans van Daalen i...@hedaal.nl To: ICS support mailing twsocket@elists.org Sent: Tuesday, March 01, 2011 10:22 AM Subject: Re: [twsocket] HttpNoBasicAuth it's time for a rewrite from scratch IMO. And give it a different name, to bypass the no brake early code rule, or some of the annoyances will have to remain. Or start a new branch of renewed components. And, IMHO, if technically possible, the THttpCli should mix HTTP and HTTPS, and handle internally what protocol to use, based in the current URL, that can originate from an usual HTTP to HTTPS redirect. In my opinion, the future cross platform Delphi which will come sooner or later (hopefully sooner) will be the best candidate for a rewrite. It will be ICS V8. Given the fact that even the basic function (GetASync) is broken and hard to correct IMHO waiting for a next version of delphi is to late to start ( planning ) a rewrite. During my tests last week it did not trigger OnRequestDone on relocations with StatusCode = 0 any more and that worked thru a proxy as well with different types of authentication. www.microsoft.de is good for testing relocations (3 or 4) and you should setup a proxy for testing as well, Squid for Windows seems to work quite well with basic, ntlm and digest, however with NTLM it reqiures a user code in the form of domain\username -- 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 -- 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 We need the option to have THttpCli trigger OnRequestDone with 301/302/307s as backwards compatibility. Regards, SZ -- 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] FTP proxy always passive mode?
the TFtpClient always sets passive mode internally with native FTP-proxy connections, this is not correct IMO. I've got no problem in that being changed. I thought SSL set passive mode automatically but that does not happen according to my recent SSL testing. Let the user choose. Angus -- 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] THttpWebserver and php
I've looked into the usermade page, but which sample do you refer to? HTTPCLIEXAMPLE.ZIP ? regards Albert - Original Message - From: Arno Garrels arno.garr...@gmx.de To: ICS support mailing twsocket@elists.org Sent: Monday, February 28, 2011 10:46 PM Subject: Re: [twsocket] THttpWebserver and php Fastream Technologies wrote: We have a working code for CGI1.2 for ICS. It's in pascal and used in IQWF Server (http://www.fastream.com/iqwebftpserver.php). You may contact me privately for this (gates AT fastream DOT com). There's an old example on the user-made page, that will probably work with current ICS and a few changes/patches. -- Arno Garrels Regards, SubZero On Mon, Feb 28, 2011 at 4:18 PM, A Drent albert.dr...@rug.nl wrote: Hi Francois, I am/was using your THttpServer component. I'll try your approach of using the HttpAppSvr component though. Don't have much experience with pipes, but there are a lot of samples regarding this. I will let you know how I progress, it might be nice to others too. tnx, Albert - Original Message - From: Francois PIETTE francois.pie...@skynet.be To: ICS support mailing twsocket@elists.org Sent: Monday, February 28, 2011 3:13 PM Subject: Re: [twsocket] THttpWebserver and php btw: I answered assuming you are using THttpAppSrv component, but looking at your subject, maybe you are using THttpServer component. I suggest you use the former which is more powerful and easier. -- 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 - Original Message - From: Francois PIETTE francois.pie...@skynet.be To: ICS support mailing twsocket@elists.org Sent: Monday, February 28, 2011 2:39 PM Subject: Re: [twsocket] THttpWebserver and php Hi Albert, I found some entries regarding this issue, but could not find a sufficient answer. If I want to use the ICS webserver to facilitate a php program (I don't mind invoking php as a cgi in my case) what's the best approach. Has someone done this before? I never done it before, but at first glance, invoking a CGI from an ICS webserver application is not difficult. Invoking a CGI require the following actions: 1) Create a lot of environment variables with informations about server, client and request 2) Create pipes for input and output 3) Create the CGI process with I/O redictions to the pipes 4) Write the client request into the pipe redirected to CGI input 5) Read the pipe used for CGI output redirection until the CGI exit 6) Send the data read from the pipe to the client as the answer to the request. A single TUrlHandlercan do all of that, probably creating a worker thread to read/write the pipes and launch de CGI executable. CGI specifications can be found here: http://www.w3.org/CGI/ Now executing a request implemented as a PHP script involve deriving form TUrlHandler handler above and executing PHP interpreter configured as a CGI. I hope this helps. -- 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 -- 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 -- 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] HttpNoBasicAuth
Fastream Technologies wrote: During my tests last week it did not trigger OnRequestDone on relocations with StatusCode = 0 any more and that worked thru a proxy as well with different types of authentication. www.microsoft.de is good for testing relocations (3 or 4) and you should setup a proxy for testing as well, Squid for Windows seems to work quite well with basic, ntlm and digest, however with NTLM it reqiures a user code in the form of domain\username We need the option to have THttpCli trigger OnRequestDone with 301/302/307s as backwards compatibility. It never worked, it was buggy as hell. Sometimes OnRequestDone triggered sometimes not and with error code null, do you realy want that 'feature' back? There's the OnLocationChange event that should be used instead to handle relocations IMO. -- 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] HttpNoBasicAuth
On Tue, Mar 1, 2011 at 1:07 PM, Arno Garrels arno.garr...@gmx.de wrote: Fastream Technologies wrote: During my tests last week it did not trigger OnRequestDone on relocations with StatusCode = 0 any more and that worked thru a proxy as well with different types of authentication. www.microsoft.de is good for testing relocations (3 or 4) and you should setup a proxy for testing as well, Squid for Windows seems to work quite well with basic, ntlm and digest, however with NTLM it reqiures a user code in the form of domain\username We need the option to have THttpCli trigger OnRequestDone with 301/302/307s as backwards compatibility. It never worked, it was buggy as hell. Sometimes OnRequestDone triggered sometimes not and with error code null, do you realy want that 'feature' back? There's the OnLocationChange event that should be used instead to handle relocations IMO. Yes we have had to override SetReady() and some other methods to get it to work for us as well. The point is, when writing a proxy such as the one we do, you need to have a tunnel mode. I think when followrelocation is not set, it should be triggered. Regards, SZ -- 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] Never trust proxy servers :)
TFtpCli - FTP 3proxy (NLST active) --- 220 Ready USER ics@192.168.178.200 331 ok PASS ics 230 Logged on PORT 192,168,178,200,5,165 200 OK NLST 503 Bad sequence of commands. FTP 3proxy - FTP server (NLST active) --- 220 FileZilla Server version 0.9.24 beta USER ics 331 Password required for ics PASS ics 230 Logged on NLST 503 Bad sequence of commands. Same in passive mode however works with LIST. -- 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] HttpNoBasicAuth
Fastream Technologies wrote: On Tue, Mar 1, 2011 at 1:07 PM, Arno Garrels arno.garr...@gmx.de wrote: Fastream Technologies wrote: During my tests last week it did not trigger OnRequestDone on relocations with StatusCode = 0 any more and that worked thru a proxy as well with different types of authentication. www.microsoft.de is good for testing relocations (3 or 4) and you should setup a proxy for testing as well, Squid for Windows seems to work quite well with basic, ntlm and digest, however with NTLM it reqiures a user code in the form of domain\username We need the option to have THttpCli trigger OnRequestDone with 301/302/307s as backwards compatibility. It never worked, it was buggy as hell. Sometimes OnRequestDone triggered sometimes not and with error code null, do you realy want that 'feature' back? There's the OnLocationChange event that should be used instead to handle relocations IMO. Yes we have had to override SetReady() and some other methods to get it to work for us as well. The point is, when writing a proxy such as the one we do, you need to have a tunnel mode. I think when followrelocation is not set, it should be triggered. Yes it should, get latest ICS from SVN and give it a trial, report any bugs to the list. Working around ICS bugs in your own derived components isn't realy a good idea since ICS doesn't keep bugs just for backwards compatibility. Better fix the ICS-component and send the SVN-patch file created from latest SVN-revision to this list. -- 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] FTP proxy always passive mode?
Angus Robertson - Magenta Systems Ltd wrote: the TFtpClient always sets passive mode internally with native FTP-proxy connections, this is not correct IMO. I've got no problem in that being changed. I thought SSL set passive mode automatically but that does not happen according to my recent SSL testing. Let the user choose. I think so as well, only it might be a breaking change from the POV of component users? Hopefully a warning in the comments and the SVN change log is sufficient. -- 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] udp packet loss
Is it right? This is like I do in my real application. IMO it isn't. If sending full speed, forget the timer and only use the event. When using the timer, check a flag you set in OnDataSent. if falg not set, do not send anything, just exit the timer event handler, data will be sent on next tick. Yesterday I have done some tests. I've tried different computers. I noticed that: On localhost I can reach very different max bitrates. From about 90Mbps under winXp (cpu=T2300@1.66GHz), until 250Mbps under win7 (cpu=I72630QM@2.00GHz), but always some packet are lost. In my opinion, sending back to back UDP packet will almost always result in packet lost. This is because the thread receiving data could be suspended for at last 20 mS or even much much more (Windows is not a real time OS). Winsock buffer must be large enough to buffer all data while thread is suspended and even larger since it has to somehow empty the buffer (Remember UDP has no flow control). You can set winsock to use a larger buffer (default is 8KB is memory serve me well). If I open wireshark many more packets are lost by the application (not by wireshark). Wireshark do not loose packet because it has a Windows Driver running in kernel mode and working using interrupt, packets are buffered in memory and that buffer is displayed by the GUI independently (just like you are browsing a database). Of course you can do that as well, but not with ICS which only works in usermode. -- 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 - Original Message - From: emanuele bizzarri e.bizza...@e-works.it To: ICS support mailing twsocket@elists.org Sent: Tuesday, March 01, 2011 10:11 AM Subject: Re: [twsocket] udp packet loss Hi Francois, hi all I cannot reproduce the packet loss on localhost. Strange. I always lose some packets on localhost (at least setting Interval=0 on the client). I can reproduce on different computers, but I found a flaw in your design: remember TWSocket use non blocking. SendTo will fail if winsock is not able to receive data and you don't check that condition. Yes you're right. Now I've modified the code like this: procedure TForm1.OnTimer(aSender:TObject); begin if fWS.State=wsConnected then begin move(fCounter,fData^,4); if (fWS.SendTo(fPeerSrc,fPeerSrcLen,fData,fDataSize)0)or (WSocket_WSAGetLastError=WSAEWOULDBLOCK) then inc(fSent); end; end; procedure TForm1.WSocketDataSent(Sender: TObject; ErrCode: Word); begin if fSent0 then begin dec(fSent); inc(fCounter); inc(fBR,fDataSize); Restart; end; end; Is it right? This is like I do in my real application. I'm not sure you correctly checked with wireshark that all packets where sent actually because their aren't when SendTo fails. I'm pretty sure yes. I've set internal packet number equal to wireshark packet number. Inside wireshark, if I select one lost packet by the server application, I can see that internal packet number corresponds. So I think that this client side bug is not the cause of packet loss. However I've fixed it. Yesterday I have done some tests. I've tried different computers. I noticed that: On localhost I can reach very different max bitrates. From about 90Mbps under winXp (cpu=T2300@1.66GHz), until 250Mbps under win7 (cpu=I72630QM@2.00GHz), but always some packet are lost. On different machines, connected with a cross cable and Gbps ethernet cards (I've installed the udp server over Q9300 2,5GHz machine, using different operating systems), max bitrate is always about 160Mbps but: under winXp a lot of packets are lost. under win7 less packets are lost than using winXp. under ubuntu+wine less packets are lost than using winXp and about the same as win7. If I open wireshark many more packets are lost by the application (not by wireshark). I noticed that if I set: SetPriorityClass (GetCurrentProcess, HIGH_PRIORITY_CLASS); and fUDPServer.Priority:=tpNormal less packets are lost (no improvement if I set also fUDPServer.Priority:=tpTimeCritical); I've tried to compile a third party example of udp server that use winsock in a different way: http://www.tenouk.com/Winsock/Winsock2example9.html under windows and under linux, but the results are like the same. I've also tried Indy project, but no improvement has been obtained. I don't know if my tests are completely correct, but my conclusion is that the mechanism of messaging notification used by windows can create a udp rx bottleneck in some circumstances (system wide and not only application wide). In my real application (where bitrates are two orders of magnitude lower) I've create a thread pool to manage incoming and outcoming data. Data are transferred by threads using async queues (that use win messages) with skip data mechanism where possible. The result is that, however, udp rx is very (too much)
Re: [twsocket] How to set in GSSLEAY_DLL_Name under BCB2010?
GSSLEAY_DLL_Name = SSLEAY32.DLL; doesn't seem to work! well it should. could be a problem with installation? maybe you're missing some of the #pragma's in the cpp file? -- 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] FTP proxy always passive mode?
I think so as well, only it might be a breaking change from the POV of component users? Making passive mode the default might be safer, since this works more often than non-passive. Would not effect any application that sets the mode specifically. Angus -- 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] THttpWebserver and php
On 01-03-2011 10:06, A Drent wrote: I've looked into the usermade page, but which sample do you refer to? HTTPCLIEXAMPLE.ZIP ? ICS_WebInterface.zip This one may help too http://users.telenet.be/ws36637/ -- 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] THttpWebserver and php
tnx, albert - Original Message - From: RTT p...@sapo.pt To: ICS support mailing twsocket@elists.org Sent: Tuesday, March 01, 2011 4:29 PM Subject: Re: [twsocket] THttpWebserver and php On 01-03-2011 10:06, A Drent wrote: I've looked into the usermade page, but which sample do you refer to? HTTPCLIEXAMPLE.ZIP ? ICS_WebInterface.zip This one may help too http://users.telenet.be/ws36637/ -- 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
