Re: [twsocket] Making ServerClass of THttpServer and TFtpServerproperty
Yes, Right+Click|TortoiseSVN|RepoBrowser. From the RepoBrowser, you specify the URL to the repository. If you happen to be in any sub-node within the repository, just change to a parent node and hit F5 to reload it, and it will show all children nodes. -dZ. >--- Original Message --- >From: Fastream Technologies[mailto:[EMAIL PROTECTED] >Sent: 11/19/2008 1:52:33 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Making ServerClass of THttpServer and TFtpServerproperty > >OT: Is there any way to browse the contents of SVN repository from Tortoise? Regards, SZ On Wed, Nov 19, 2008 at 2:38 PM, Arno Garrels <[EMAIL PROTECTED]> wrote: > Fastream Technologies wrote: > > Yes we plan to update to v7. I just need to know whether it would > > work with BCB2007 or do I have to update to BCB2009 for FTPS/HTTPS > > Server components? > > It should work with CB2007, checkout latest SVN revision from > /branches/icsv7/. > > -- > Arno Garrels > > > > > On Tue, Nov 18, 2008 at 7:40 PM, Francois PIETTE > > <[EMAIL PROTECTED]>wrote: > > > >>> I doubt that Francois wants such basic changes in V6 which is a > >>> release candidat now. > >> > >> Indeed. Probably SZ could already use V7 ? > >> V7 is the workhorse ! > >> > >> -- > >> [EMAIL PROTECTED] > >> 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: "Arno Garrels" <[EMAIL PROTECTED]> > >> To: "ICS support mailing" > >> Sent: Tuesday, November 18, 2008 5:47 PM > >> Subject: Re: [twsocket] Making ServerClass of > >> THttpServerandTFtpServerproperty > >> > >> > >>> Fastream Technologies wrote: > >>>> If we decide to sponsor such a coding job, would any of you guys do > >>>> it for the benefit of all? If so, for how much USD and days? > >>> > >>> Now that the V7 FTP server uses the TWSocketServer (thanks Angus) > >>> it's an easy task. I'm sure you code that in a few minutes, look at > >>> how it is done with the client class and you get the idea. If you > >>> want it for V6 the Ftp server needs to be rewritten first which was > >>> much more work (I doubt that Francois wants such basic changes in > >>> V6 which is a release candidat now). > >>> > >>> -- > >>> Arno Garrels > >>> > >>>> > >>>> Best Regards, > >>>> > >>>> SZ > >>>> > >>>> On Sat, Nov 1, 2008 at 9:12 PM, Angus Robertson - Magenta Systems > >>>> Ltd < [EMAIL PROTECTED]> wrote: > >>>> > >>>>>> Angus already made an attempt to rewrite the FTP server, but it > >>>>>> never made it into the ICS package :( > >>>>> > >>>>> I do finally shortly expect to start adding UTF-8 and a couple of > >>>>> new commands to the V7 FTP server, and there's no reason that can > >>>>> be based on the SocketServer version, leaving the V6 version > >>>>> using the legacy private server. > >>>>> > >>>>> 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 > >>> -- > >>> 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] THttpCli.Head bug
When I telneted in, I typed HEAD and hit ENTER with no proper request string (no document resource) and it got stuck. I did the same thing with GET and I got the standard error for a bad request. I thought it was our proxy here. There seems to be something wrong with the server then. -dZ. >--- Original Message --- >From: Fastream Technologies[mailto:[EMAIL PROTECTED] >Sent: 11/5/2008 12:56:32 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] THttpCli.Head bug > >There is no proxy in between now. It must be a web server issue as the jpg also does not respond to head!. On Wed, Nov 5, 2008 at 6:50 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I just tested this using telnet, and just typing HEAD > (even if the request is invalid) will cause the > transaction to fail in a weird way. My guess is that > the problem is at the gateway (perhaps a proxy > configuration issue?), or maybe the HTTP server itself. > >-dZ. > > > > >--- Original Message --- > >From: Francois > PIETTE[ mailto:[EMAIL PROTECTED] > >Sent: 11/5/2008 12:35:24 PM > >To : twsocket@elists.org > >Cc : > >Subject : RE: Re: [twsocket] THttpCli.Head bug > > > >> Please use the ICS HttpTst and HEAD to, > > http://secure.iconsole.org/login.ews > > GET works HEAD fails--causes trouble for our > reverse proxy. Any ideas? > > I can reproduce the issue, even with command line telnet. > IMO it is a bug of that website. login.ews probably > correspond to a script > which crashes with the head command. > > -- > [EMAIL PROTECTED] > 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 > -- Gorkem Ates Fastream Technologies Software IQ: Innovation & Quality www.fastream.com | Email: [EMAIL PROTECTED] | Tel: +90-312-223-2830 | MSN: [EMAIL PROTECTED] Join IQWF Server Yahoo group at http://groups.yahoo.com/group/IQWFServer Join IQ Reverse Proxy Yahoo group at http://groups.yahoo.com/group/IQReverseProxy -- 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] THttpCli.Head bug
I just tested this using telnet, and just typing HEAD (even if the request is invalid) will cause the transaction to fail in a weird way. My guess is that the problem is at the gateway (perhaps a proxy configuration issue?), or maybe the HTTP server itself. -dZ. >--- Original Message --- >From: Francois PIETTE[mailto:[EMAIL PROTECTED] >Sent: 11/5/2008 12:35:24 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] THttpCli.Head bug > >> Please use the ICS HttpTst and HEAD to, > http://secure.iconsole.org/login.ews > GET works HEAD fails--causes trouble for our reverse proxy. Any ideas? I can reproduce the issue, even with command line telnet. IMO it is a bug of that website. login.ews probably correspond to a script which crashes with the head command. -- [EMAIL PROTECTED] 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
Re: [twsocket] OT: Is the list still alive?
I received your message fine. Yet, it is indeed strange that there haven't been any messages for a week. -dZ. >--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] >Sent: 10/29/2008 12:46:34 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] OT: Is the list still alive? > >Hi, Six days no messages, very strange... -- 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] TTcpDaemon in ICS V7
I think you should be able to use conditional compiler directives for that. I believe there's a file included with the ICS distribution that defines various delphi compiler versions and such. -dZ. >--- Original Message --- >From: Jon Robertson[mailto:[EMAIL PROTECTED] >Sent: 10/3/2008 12:43:16 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TTcpDaemon in ICS V7 > >> I changed the file naming scheme to the V7 scheme and changed a few "char in []" to "CharInSet()". > I think those were the only changes. These demos work great for me in D2009. Argh, it just dawned on me that the CharInSet changes will only work with D2009. Anyone else should change that back to "char in []" I'm still wrapping my head around Unicode and will be for a while. I'm almost comfortable just leaving things alone, taking for granted that most of what I'm used to in D6 will "just work". Jon -- 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] Early web server response
QUOTE: I not convinced of this. The title of the section is "Monitoring Connections for Error Status Messages". So when it say "SHOULD monitor the network connection for an error status" I think that it refers to the connection itself and not to an error reported by the server. Wow, you bring a very interesting point. I was interpreting "error status" as an error response, but now I think you are right: it seems to mean that the connection must be dropped when the TCP/IP connection itself fails while transmitting. I don't know how I missed this. If this is the case, then early error responses are not supposed to happen (since, as I said before, they do not seem to be mentioned anywhere). QUOTE: So the connection and what the server send are two different thinks. I consider "sees the connection close" one of the possible results of "monitor the network connection for an error status". Yes, you are right. I'm sorry, I appear to have misunderstood the semantics of section 8.2.2 of the RFC. QUOTE: Yes. I waited at least one minute before confirm the authentication form. What WireShark showed me is that the request was incomplete and the second try was made with a new connection. If I confirm immediately then all is done in the same connection, and of course the re-send is made after the first is completed. I'm sorry but I'm confused. What caused IE to open a new connection? When you say "I confirm", do you mean that you submit a username and password when IE prompted you? Perhaps the new connection is because of a very short nonce time-out? QUOTE: I repeat the same with Firefox (3.0.2) with similar result. The difference seems that FF ask for user and password after it has finished to send the request. Effectively I get the password request a bit later compared to IE. Even FF do a new connection if I wait to confirm the authentication form. In that case I see in WS that the first request is sent entirely. OK, so it is what we have suspected all along: Both browsers receive the early 401 response but continue sending the full content, and then re-send the request with the authorization headers. The difference is that IE prompts the user as soon as it receives the response (early), while Firefox waits until it finishes transmitting the body (late). I think then that Arno's solution would work, since it seems to have the same effect: delay the re-try until after the body is sent completely. I still think this offers a vector for Denial-Of-Service attacks. However, sending the response early does not protect you since, as we saw, the client is free to delay reacting to the response. I agree with you that if this was the concern of Tomcat, it would have closed the connection. So why does Tomcat respond early? -dZ. -- 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] Early web server response
QUOTE: > Yes, but the response came while the body was in > transit already, before it was sent completely, which > puts the transaction in a very unstable state. This > is the reason why the RFC requires the client (i.e. > it says it "MUST") close the connection if the > Content-Length header was used. Can you point me where the rfc say this? Is it the 8.2.2? Yes, section 8.2.2 says: "[...] If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (section 3.6), a zero length chunk and empty trailer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection." http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2 As I mentioned in my previous message, I believe that this requirement is because the server responded early for a reason: it rejected the request, so sending the rest of the body to satisfy the Content-Lenght would go against the wishes of the server. As we have seen, to compensate for this, the server "accepts" the body, but silently discards it (at least that seems to be the behaviour). This means that the server is wasting resources in attending a rejected request. QUOTE: You said that the client MUST close the connection when receive the 401. Is the section above that you are referring? Ah! I'm very sorry, but I think you may have misunderstood me. I said that the RFC (section 8.2.2, as quoted above) states that IF an error response is received early AND a Content-Length header was used THEN the client MUST close the connection. QUOTE: What is still not clear to me is: sending the response before the client has finished to send the request break the rfc or not? No. Sending the response before the client has finished sending the request is allowed by the RFC. This is also in secion 8.2.2: "An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request." I can't find any place where it explicitly states that responses can come before the end of the request. Nor can I find a place where it explicitly states that the server must receive the full request before sending a response. The RFC seems to imply that the standard way is for a response to follow the full request; but parts like section 8.2.2 seem to imply that this is not a requirement. For example, in section 6: "After receiving and interpreting a request message, a server responds with an HTTP response message." It does not expressly say that the server must respond at the end of the request, just after interpreting it. Arguably, an unauthorized request for a resource that requires authentication can be clearly "interpreted" and identified as soon as the headers are received and processed. In any case, the wording in section 8.2.2 seems to suggest it strongly. QUOTE: If this was for security reasons why the server doesn't close the connection? As it is actually it receive the rest of the request (at least if made by IE). Exactly, it's a tricky situation. On the one hand, the server does not want to process a lengthy request which it *knows* is invalid. On the other hand, it is bound by the RFC to receive the full length of the body, as specified in the Content-Length header. The RFC therefore puts the responsibility on the client by saying that it MUST close the connection in such cases. If the client closes the connection, then everything falls into place: The client can re-connect and re-send the request with the appropriate authentication header (if it has the credentials), and the server can easily ignore the previous unauthorized request. All is well except for NTLM, which requires the connection to be kept open. By the way, when I said "security reasons", I meant to prevent a Denial-Of-Service attack. QUOTE: > If a Content-Length header was provided, the client > MUST close the connection. IE don't do so, but works (ok, it is a M$ product, following the rules is not very frequent ;). Are we confident that IE received the response early? Perhaps it defers acknowledging responses until after the body is fully sent. (The RFC does say that the client "SHOULD" monitor for early error responses, it does not say they "MUST".) Also, as we have seen, the RFC seems a little vague in this regard, so it is entirely possible that this particular exceptional case was not considered too much. RFC 2616 does not discuss authentication at all, it was deferred to RFC 2617; but that RFC does not consider transport problems (since that is part of RFC 2616). Furthermore, RFC 2616 has this to say about Denial Of Service Attacks: "They exist. They are hard to defend against. Research continues. Beware. " Which does not help much. In any case, if it works for IE, it can work for us. Perhaps Firefox works
Re: [twsocket] Early web server response
Ok, that makes more sense. And, just to make sure I understand, here's the sequence of events: 1. IE Sends request without auth information. 2. Server responds with 401 after the headers are received. 3. IE continues sending whatever was in send buffer (up to Content-Lenght bytes) but stops when the 401 response is received. 4. Server receives the bad data (whatever IE sent after the 401 response) and discards it without problem (up to Content-Length bytes). 5. IE then pauses to ask the user for login information. 6. IE re-sends the request with valid auth credentials and the entire payload as normal. 7. Server authenticates the connection and accepts the request. Is the above accurate? If so, then what is the problem? If the server silently discards the payload data from the unauthorized request, then surely there is no problem with HttpCli, unless it is sending more than Content-Length data and the server is interpreting the extraneous data as a new request. -dZ. >--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] >Sent: 9/23/2008 3:04:54 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Early web server response > >[EMAIL PROTECTED] wrote: > So, if I understand correctly, part of the body was > sent after the 401 response (that which was in the > send buffer already), and the remainder was sent > after the authentication header was sent? My mistake, there are too many packets in the log. Actually IE resends everything when it received the 401 response. -- Arno -- 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] Early web server response
So, if I understand correctly, part of the body was sent after the 401 response (that which was in the send buffer already), and the remainder was sent after the authentication header was sent? This is weird. It means that the server accepted the (invalid) data that was sent after a non-authenticated request. This smells like a security vulnerability. Or am I misunderstanding it? -dZ. >--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] >Sent: 9/23/2008 2:25:24 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Early web server response > >Arno Garrels wrote: > 3) IE then sends just the header with the credentials and continues > posting the rest of the data. :-) Should read "IE then sends just the header with credentials and continues posting remaining data." -- Arno -- 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] Early web server response
Maurizio, Is this test server the Tomcat server where the issue manifested before? QUOTE: At this point the problem seems quite different. The "early" receive of the 401 interrupt the sending of the body. So the server "drop" what receive until the content length is reached, and then consider the rest as a new request. === END I'm not sure I understand. Do you mean that the server did send an early 401 response but allowed the client to send up to Content-Length-amount of data? So, then there's no problem, right? I though that as soon as it sent the response, all the rest of the request (the body) was being treated as a new request from the server and failing as invalid. Unless you were sending more data than you specified in the Content-Length before... I'm confused. I don't have access to WireShark right now, so I can't really test this at the moment. -dZ. >--- Original Message --- >From: Maurizio Lotauro[mailto:[EMAIL PROTECTED] >Sent: 9/23/2008 12:32:24 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Early web server response > >Scrive Maurizio Lotauro <[EMAIL PROTECTED]>: > Scrive DZ-Jay <[EMAIL PROTECTED]>: [...] > > In any case, I'll see if I can do some experiments with IE and Tomcat > > and let you know what I find. > > Please wait, I asked to our server admin to prepare a test environment > public > available (I need it for myself). Probably it will be ready tomorrow. I have a public server that show the problem. Who is interested write me an email. I made some test with a test application and IE. The latter works. Analyzing the communication with WireShark it seems that it works because IE complete to send the whole body before resend the request including the authorization info. At this point the problem seems quite different. The "early" receive of the 401 interrupt the sending of the body. So the server "drop" what receive until the content length is reached, and then consider the rest as a new request. I have a modified version of THttpCli that show automatically a user/pwd request when the status code is 401/407 (and cache it). In fact if I wait to give user and pwd then it works because in the meantime the whole body is sent. So the solution seems wait that the body is sent before retrying. Bye, Maurizio. -- 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] Early web server response
Hello: I'm sorry for the long discussions, but we have identified an issue and understanding each other is the only way to work together to solve it. Please read below for my responses. I would take this off-list, except for the fact that it is a discussion on the implementation of HTTP protocols, which I think is relevant to this list. If not, please let me know. dZ. Maurizio Lotauro wrote: > So what I mean is that, if possible, the connection should not be closed. I agree. But my point was that since it is not required by the protocol definition, clients and servers are free to not implement re-using the connection. Because of that, for the WWW to work, both clients and servers must support their counterparts to require a new connection for each request. With HTTP 1.1, persistent connections are the default, but note that if, say, the client closed the connection before a new request (for whatever reason), the server should accept the next request as normal. And, since the protocol *is* stateless, there is no difference between sending a request within the same connection and one from a new connection. Of course, that is, no contextual difference (by which I mean not counting performance). > In that case (401) the server answer with Connection: Keep-alive, so the client > (try to) act consequently. Yes, but the response came while the body was in transit already, before it was sent completely, which puts the transaction in a very unstable state. This is the reason why the RFC requires the client (i.e. it says it "MUST") close the connection if the Content-Length header was used. If it were a normal HTTP authentication method (Basic or Digest, not NTLM), this would not be a problem: You close the connection, re-connect, and re-send the request with the proper credentials (as specified in the 401 error response). Et voila. >> (At this point, servers or clients using older versions of the HTTP >> protocol would have closed the connection.) > > Only if the client and the server doesn't include Connection: Keep-alive Agreed. >> 4. On every subsequent request, the client includes the same >> credentials and the server re-authenticates the request. (Digest has >> some differences, but generally fits this scheme). > > This should be not necessary if the connection is not closed in the meantime. > In fact if the client is still connected why it should resend the exactly same > credential every time? Because the authentication was for the *request*, not the connection, and that request was terminated the moment it was processed and a response was sent (stateless, remember?). The persistent connection is a hack in HTTP to improve performance and optimize server loads. It does not imply statefulness, which means that every request is treated as an entirely new session, regardless of connection status. Please understand this concept. This is why, in my opinion, the NTLM causes so much trouble in edge cases: because it breaks away from the standard way that the HTTP protocol works. >> [...] And in fact, this is what browsers >> do: from then on, the authentication can be done in a single request, >> without the "error" step. > > This is true for basic but I think not for digest. The challenge include a nonce > value, and the section 3.2.1 say: No, it is still true for Digest. The nonce is not the same thing as the NTLM challenge, which authenticates the *connection*. The HTTP protocol allows for a client to close the connection, re-connect and send the nonce in the next request (along with the rest of the authentication details). This is why it allows for a time-stamp or other replay-proof mechanisms. Note that it does not require that all requests are sent through the same connection. Or do you think that Digest was not supported until HTTP 1.1, when persistent connections were the default? >> Another way that NTLM breaks away from the protocol is that, once the >> connection is authenticated, subsequent requests within the same >> connection need not perform the challenge-response. > > I don't agree with you. In a previous post I think you refer to this (from rfc > 2616): > > ---8<--- > 8.2.2 Monitoring Connections for Error Status Messages > [...] > It speak about a network connection and not an error reported by the server. In > fact: I'm not sure how this has to do with what I said above. I stand by my comment: The HTTP protocol (version 1.0 and 1.1) is stateless and requires that every request contain all the information the server needs to process it. In the case of the Digest Authentication, the WWW-Authenticate header needs to be submitted with the appropriate authenticated digest hash on every request--regardless of whether they are in the same connection or not. By contrast, NTLM does not require this. Once it authenticates the connection (notice again the difference between authent
Re: [twsocket] Early web server response
Thank you. I understand then. That obviously invalidates my suggestion. However, I wonder how this works in practice. I mean, how do regular browsers deal with it? The RFC specifically states that if you receive an error after the headers, and you used a Content-Length header, you MUST (their emphasis) drop the connection. Perhaps it's done with "chunking"? -dZ. >--- Original Message --- >From: Fastream Technologies[mailto:[EMAIL PROTECTED] >Sent: 9/19/2008 12:54:58 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Early web server response > What you miss is NTLM 401 response includes some random data that must be returned with the request in the same connection. Otherwise value would be lost at server side!! -- 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] Early web server response
>--- Original Message --- >From: Maurizio Lotauro[mailto:[EMAIL PROTECTED] >Sent: 9/19/2008 11:24:14 AM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Early web server response > > This will work with Basic bu not with NTLM because (IIRC) > the authentication phase is started by the server with the > first 401. > > Is there a way to empty the socket buffer? Again, I must be missing something (I admit I am not very familiar with NTLM authentication). So the server sends a 401 error response, your client detects this right after sending the header, while in the process of sending the body. It then reacts immediately by terminating the connection. It then re-connects and responds to the 401 response with a new request which includes the authentication header. How is this different than the normal way: You send your request completely (head and body), the server responds with a 401 error response and closes the connection (or you close the connection). You then re-connect and perform the request again with the authentication header. -dZ. -- 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] Early web server response
>--- Original Message --- >From: Maurizio Lotauro[mailto:[EMAIL PROTECTED] >Sent: 9/19/2008 10:25:03 AM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Early web server response > > I cannot close the connection, it will not > work with NTLM authentication. I'm sorry, but I don't understand. I must be missing something. As soon as you detect the error response, you close the socket, then re-connect and re-send the request with the appropriate authentication header. Granted, this is not currently supported directly by the component, but I don't see a problem in modifying it to do this. By that I mean that it may be a challenge to do so, and it may be a hack, but it's not insurmountable. Perhaps an event can be triggered after the headers are sent and an error response is received. The application can then decide, based on the error code, whether to close and retry with authentication credentials, or just close and fail. But this is all in theory, as I haven't seen the HttpCli code in a couple of years. -dZ. -- 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] Early web server response
>--- Original Message --- >From: Maurizio Lotauro[mailto:[EMAIL PROTECTED] >Sent: 9/19/2008 8:12:30 AM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Early web server response > > How I can avoid the second chunk or tell the server that I'm starting a new send? The RFC provides the answer: "If the body is being sent using a "chunked" encoding (section 3.6), a zero length chunk and empty trailer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection." Thus, if you are sending the body preceded by a Content-Length header (which is, I believe, the way the HttpCli sends by default), then you must close the connection immediately after detecting an error, in order to start a new one. The server may receive the particular chunk that was in transit eventually, but since you closed the connection, it won't respond to it. -dZ. -- 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] OT: Getting bounces from every post I send (WAS: We are currently on a Holiday break.)
>--- Original Message --- >From: Maurizio Lotauro[mailto:[EMAIL PROTECTED] >Sent: 9/17/2008 2:28:05 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] We are currently on a Holiday break. > > Am I the only one? No, I am also getting the same message for every message I send to the list. Francois, could you look into this? -dZ. -- 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] Early web server response
>--- Original Message ---
>From: Arno Garrels[mailto:[EMAIL PROTECTED]
>Sent: 9/17/2008 2:09:29 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] Early web server response
> I don't think it's current THttpCli's behaviour.
How to handle
> authentication methods depending on keep-alive with
POST, if the
> connection has to be dropped?
Well, according to the RFC, this is not exclusive to
authentication methods; *any* request could be
"cancelled" at any time if the server decides to not
accept it based on the headers. This means that
after sending the headers, the client must ("should"
according to the RFC) monitor for a response.
Section 8.2.4 of RFC 2616 has something to say about
this:
8.2.4 Client Behavior if Server Prematurely Closes
Connection
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.4
"If an HTTP/1.1 client sends a request which
includes a request body, but which does not include
an Expect request-header field with the
"100-continue" expectation, and if the client is not
directly connected to an HTTP/1.1 origin server, and
if the client sees the connection close before
receiving any status from the server, the client
SHOULD retry the request. If the client does retry
this request, it MAY use the following "binary
exponential backoff" algorithm to be assured of
obtaining a reliable response:
1. Initiate a new connection to the server
2. Transmit the request-headers
3. Initialize a variable R to the estimated
round-trip time to the
server (e.g., based on the time it took to
establish the
connection), or to a constant value of 5
seconds if the round-
trip time is not available.
4. Compute T = R * (2**N), where N is the
number of previous
retries of this request.
5. Wait either for an error response from the
server, or for T
seconds (whichever comes first)
6. If no error response is received, after T
seconds transmit the
body of the request.
7. If client sees that the connection is closed
prematurely,
repeat from step 1 until the request is
accepted, an error
response is received, or the user becomes
impatient and
terminates the retry process.
If at any point an error status is received, the client
- SHOULD NOT continue and
- SHOULD close the connection if it has not
completed sending the
request message.
===END_OF_QUOTE
Perhaps we can implement something like this?
-dZ.
--
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] Early web server response
Hello: Actually, I just found that this is defined in the RFC (probably to prevent DOS attacks): 8.2.2 Monitoring Connections for Error Status Messages http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2 "An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (section 3.6), a zero length chunk and empty trailer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection." If this is not the current behaviour of the HttpCli component, then perhaps we can work in implementing this. -dZ. -- 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] Early web server response
Hello: It occurs to me that it could be a mechanism to protect from a DOS attack. Consider the following attack vector: You encounter a server which requires authentication for a resource. You then flood the server with POST requests with very large payloads, requiring the server to receive the entire request before formulating the 401 response. With a large enough flood, you can overwhelm the server and cause denial of service. I guess a way to overcome this in the client side would be to send a HEAD request prior to establish if the resource is available for consumption. If not, the server will respond with 401 and your client can then send the appropriate authentication credentials. Also, if the server is responding prematurely, doesn't it mean that the request connection was aborted? And if this is the case, shouldn't the HttpCli component detect this and stop sending? This still won't prevent any data currently in transit from generatinga 402 error response when it arrives at the server. -dZ. >--- Original Message --- >From: Maurizio Lotauro[mailto:[EMAIL PROTECTED] >Sent: 9/17/2008 1:10:47 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Early web server response > Yes. Using "Follow TCP Stream" of WireShark I see the answer in the middle of the request. Then I checked the single packet (ordered by time) and it is effectively so. This happen by a customer that use IIS, then I reproduced it on our server (that use Apache). Maybe a Tomcat issue? Bye, Maurizio. -- 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] Early web server response
Hello: Seems to be a server issue. Even if the server requires authentication, the response should not be sent until the entire request is received. This behaviour is very strange indeed. Are you sure that the response is sent before the XML file is sent completely (i.e. the request is completed)? -dZ. >--- Original Message --- >From: Maurizio Lotauro[mailto:[EMAIL PROTECTED] >Sent: 9/17/2008 12:48:50 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] Early web server response > >Hello, it seems that I have a problem with the HttpCli component. The client send an xml to the server using the POST method (synch). The server require an authentication (basic). When the xml is greater than a certain size (160k are enough) the server answer with a 400 (IIS/Tomcat: Bad request) or 414 (Apache/Tomcat: URI too long) status code. I analyzed the communication using WireShark and this is what I observed. The server answer with 401 before the client has finished to send the xml. The client continue to send the rest of xml, but the server "think" that it is a new request and then return the error. At this point the client stop and raise an exception. I'm using ICS V5 (not the last one because I'm using a customized version). Is it a known problem solved in a more recent version? Bye, Maurizio. -- 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] ICS-SSL now released as freeware. ICS is ready for Tiburon. Version Control repository for ICS
thats great. is it possible to use ssl and non-ssl at the same time? i.e. for a pop3 client that can connect to a aecure and a nonsecure server ? > Here are a few things worth mentionning :-) > > ICS-SSL > === > As promised long time ago, ICS-SSL is now going public. > It means everybody will have free access to the source code. > ICS-SSL is nearly finished. It is already used by more than > 150 contributors, many in real commercial application with > great success. > > ICS-SSL would never have happened without all those > contributors, among two of them I would like to specially > thanks: Arno Garrels and Angus Robertson. Arno has done a > really incredible work in designing many parts of ICS-SSL > while Angus has done some development and a lot of > testing and bug fixing. Of course, I would also thanks > developers that contributed financially. Without that > money I would not have been able to work as much on the > project. > > The project is not finished ! It will simply now released > to the freeware community with the secret hope that a lot of > developers will contribute to the development. > > SSL enabled components are just the regular components > with SSL code magically inserted using a conditionla > symbol. In short, define use_ssl and suddently your > ICS components are enabled for SSL. > > There are some demos in SslInternet folder. > > It is not possible to explain everything here. Please use > the support mailing list to ask for help. > > > ICS-V7 > == > Angus Robertson, Arno Garrels and Francois Piette are proud > to announce the new ICS-V7 also known as "ICS for Tiburon". > Actually you need to have access to Delphi 2009 to use the > new unicode features but previous Delphi/BCB versions are > still OK of course. V7 is at alpha level and currently > efforts are concentrated on Delphi 2009. > Basically, ICS-V7 is ICS-V6 with partial unicode support. > Currently the components are working mostly as before > while using unicode strings. This will allows you to port > your current applications to Delphi 2009 and of course > write new applications. > We hope to fully support unicode soon. We will be happy > to have help from any ICS community member. > > > ICS-V6 > == > This is the version you should use today or at least very > soon tommorow. Currently there is a release candidate > available for download at www.overbyte.be. > > > ICS-V5 > == > This is the old version. It is still there to support > old applications. Forget it for new one. No new development > will take place and migration to ICS-V6 is easy. > > > VERSION CONTROl REPOSITORY > == > > To ease the development, for both ICS and ICS-SSL, there > is now a SVN repository. Again, I would like to thanks > Arno and Angus who both made it possible. Angus providing > the hosting while Arno providing the management. > > The repository actually contains ICS-V5, ICS-V6 and ICS-V7. > The SSL stuff has been merged into the regular ICS code > so there is only one code base. The SSL code is compiled > when the symbol use_ssl is defined for your project. > > To access the repository, you need to use a subversion > client. For example TortoiseSVN (http://tortoisesvn.net/) > which is very good and OpenSource. > > Once your SVN client is installed, for ICS-V6 you can > browse to svn://svn.overbyte.be/ics or > http://svn.overbyte.be:8443/svn/ics or for ICS-V5 to: > svn://svn.overbyte.be/icsv5 or > http://svn.overbyte.be:8443/svn/icsv5. > ICS-V7 is a part of V6, in ics/branches/icsv7. All use > usercode = ics and password = ics for read access. > Write access is only available to TeamICS. > > SVN works by keeping a local development directory in > synchronism with the repository directory. TortoiseSVN > integrates into Windows Explorer, navigate to the local > directory to which ICS will be downloaded, right click in > Explorer and take SVN Checkout, enter the URL from above, > ensure the local directory is correct and click to > download the files. Subsequent changes are found by right > clicking in the root and taking SVN Update which will just > download anything changed or new. > > You are really welcome to participate in the development > and submit your fixes and changes. To do so, simply use > TortoiseSVN "diff file" facility and make your changes > available somewhere and announce it in the support > mailing list (or mail it to one of TeamICS member). > > If you need help, please use the support mailing list. > > Best regards > -- > [EMAIL PROTECTED] > 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
Re: [twsocket] Post command...
zayin wrote: > I do not know enough about all the HTML codes to know if I am missing some. > Like "refresh current page" or reload or simple "acknowledge do nothing". There are no such responses. The response codes are typically status codes as a result of the request (error, success, file-not-found, file-found-somewhere-else, etc.). In your case, a successful processing should reply with 200, which means "success". However, this is only the response header, you still need the body. If you leave it blank, the browser will just display a blank page, which is even worse. > It appears that the only solution is to just retransmit the complete page > after the button is pressed. This is the quick solution. Since the protocol is "stateless", there is really no way to say "Success, now reload the page" -- the browser needs to *give* the client the page to reload it. The alternative is to do it in JavaScript, which may be more difficult. -dZ. -- 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] Post command...
Mark,
First you need to understand how HTTP works: It is
a stateless protocol, and it works in a
"request-response" cycle. The "stateless" part means
that it doesn't retain any information about any
previous requests or responses, and that every
request is treated as a completely new one. The
second part means that when the client sends a
request, the browser returns a response.
When you use a browser as a client, a "request" is
any URL you enter in the address bar or hyperlink you
click on, which is sent to the server; and this
causes a "response" from the server, which, depending
on the type of resource it returns, is treated in a
specific way. For instance, an HTML resource is
rendered as a web page, and a JPEG resource is
rendered as an image.
Every request expects a response, this is the way
the protocol was designed, so there is no clear way
to say to the server "Do this and then don't give me
anything back". But then whatever the server gives
back to the browser, the browser will try to
interpret it as best as it can -- even if you make
the server return an empty resource, the browser will
just display an empty web page. This is clearly not
what you want.
For this reason what is typically done is that when
a page requests some processing from the server that
should "return nothing" or "cause no change", the
server returns the original content so that the
browser can render it equally as if nothing happened.
That's what I was showing how to do. This is a
typical "state-machine" type of application, where
depending on the "state" of the application (either
first request, or form post), the server does
something different.
An alternative is to not use the browser directly to
perform the request for processing, but to use
JavaScript, as Francois suggested. This way,
whatever the server responds -- and it will *always*
respond with something -- you can throw it away or
interpret it as you want (using JavaScript).
The point is that in order for the browser to stop
"waiting", the server has to respond with something
-- *anything* (even an empty response body, just the
headers); and whatever it responds with, the browser
will try to act upon it. A web application is not
the same as a Win32 application.
dZ.
zayin wrote:
> Hi,
>
> Thanks for the information.
>
> What I am looking to do is just stop the client
browser from waiting. I do
> not want to change the page.
>
> In the two environments I am testing in, at
present, IE and Mozilla, after
> the user presses the "accept" button the browser
waits for a reply. With IE
> the tabsheet title shows a spinning circle. With
Mozilla it sets the cursor
> to the pointer+hourglass.
>
> After the HandlePostedData I do not know what to
send to handle the client
> so the client stop this "wait" mode.
>
> Ciao,
>
> Mark
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Monday, April 14, 2008 10:54 AM
> To: twsocket@elists.org
> Subject: Re: [twsocket] Post command...
>
> Mark,
> If what you want is to let the user know that
processing has
> completed, what you need to do is quite simple, old
school CGI processing:
> You change the rendered output to reflect the
results of processing.
>
> After finishing processing, change a variable,
say, "resultString",
> and display it in the rendered output. You can
have something like:
>
> // Notice the call to GetResultString() to inject
server output.
> AnswerString(Flags,
> '', { Default Status '200 OK' }
> '', { Default Content-Type: text/html }
> '', { Default header }
> '' +
>'' +
> '' + TitleString + '' +
>'' +
>'' +
>GetResultString(resultString) +
>'' +
> //accept command action
> 'Tag:' + tagName + ' ' + cBackButton + '' +
> 'High Limit: ' + highEU + '' +
> 'Low Limit: ' + lowEU + '' +
> '' +
> '' +
> '' +
> ' value="Accept"/>' +
>'' +
> '');
>
> // ---
>
> Function GetResultString(str: String): String Begin
> If (str <> '') Then
> Result := 'Server Responded: '+ str
> Else
> Result := '';
> End If
> End;
>
> // -- END
>
> When
Re: [twsocket] Post command...
Mark,
If what you want is to let the user know that
processing has completed, what you need to do is
quite simple, old school CGI processing: You change
the rendered output to reflect the results of processing.
After finishing processing, change a variable, say,
"resultString", and display it in the rendered
output. You can have something like:
// Notice the call to GetResultString() to inject
server output.
AnswerString(Flags,
'', { Default Status '200 OK' }
'', { Default Content-Type: text/html }
'', { Default header }
'' +
'' +
'' + TitleString + '' +
'' +
'' +
GetResultString(resultString) +
'' +
//accept command action
'Tag:' + tagName + ' ' + cBackButton + '' +
'High Limit: ' + highEU + '' +
'Low Limit: ' + lowEU + '' +
'' +
'' +
'' +
'' +
'' +
'');
// ---
Function GetResultString(str: String): String
Begin
If (str <> '') Then
Result := 'Server Responded: '+ str
Else
Result := '';
End If
End;
// -- END
When the page is first rendered, the
GetResultString() function will return an empty
string because the resultString hasn't been set. And
when the data is posted and processed, it will
display the new string.
This is pretty much how more complex and
sophisticated frameworks, like ASP.NET, Java-Struts,
and PHP handle dynamically generated pages.
What Francois was offering was a more "modern" and
popular approach, usually called AJAX, where your web
page sends requests to the server on a separate
channel, using JavaScript, then parses the output,
and dynamically changes the document displayed. It
does the same thing without "refreshing" the entire
document. However, as you stated, this may not work
in exactly the same way on every browser, and depends
too much on client-side processing, which is prone to
errors and abuse.
-dZ.
zayin wrote:
> Hi,
>
> This all has to be done in HTML only.
>
> This is my first HTML programming task so, I do not
know how to "make the
> command from an invisible frame or layer".
>
> This is the page.
>
> AnswerString(Flags,
> '', { Default Status '200 OK' }
> '', { Default Content-Type: text/html }
> '', { Default header }
> '' +
>'' +
> '' + TitleString + '' +
>'' +
>'' +
>'' +
//accept command action
> 'Tag:' + tagName + ' ' + cBackButton + '' +
> 'High Limit: ' + highEU + '' +
> 'Low Limit: ' + lowEU + '' +
> '' +
> '' +
> '' +
> '' +
>'' +
> '');
>
> Can you advise?
--
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] Why does listening TWSocket reset defaults on close?
Hello: I just realized that if I close a listening TWSocket component (to stop listening), it reverts all defaults, including the listening port and address, so that if I want to start listening again, it will fail (unless I set the port). Although I can very easily work around this, I was just wondering why this is done? It seems to me that stopping a listening server from listening should not reset all its application-specific properties (specially the port and address). And it even occurs to me that its counter-intuitive to how most of the ICS components work: if you were using the component on a form, and configured it at design time (which, by the way, I don't do), then if you ever closed the socket you won't be able to listen again. Perhaps there is a valid reason for it, I just want to understand it. -dZ. P.S. I'm sorry if I have been asking a lot of questions about the same components lately, but I'm trying to get acquainted with the lower level TWSocket component. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] Closing connection in OnDataAvailable retriggers event
Hello: I'm performing various requests depending on input received in the TWSocket.OnDataAvailable event (using LineMode=True). If an invalid string is received, I need to close the connection. However, calling WSocket.Close() from within the event will cause OnDataAvailable to trigger again. I traced this to the fact that FRcvdCnt is only reset to zero after the user event returns, so when TriggerSessionClosed is called it thinks there is new data. Even if FLineFound is set to True, TriggerSessionClosed checks for the FRcvdCnt being greater than zero and calls OnDataAvailable again. The other flag it checks is FLineClearData, but this seems to *only* be set when the LineLimit has been exceeded: procedure TCustomLineWSocket.TriggerSessionClosed(Error : Word); begin FLineReceivedFlag := TRUE; if FRcvdPtr <> nil then begin // *** Perhaps FLineClearData should // be set by TriggerDataAvailable // when the FLineFound is true? if FLineMode and (FRcvdCnt > 0) and (not FLineClearData) then begin FLineLength := FRcvdCnt; while FLineMode and (FLineLength > 0) do inherited TriggerDataAvailable(0); end; FreeMem(FRcvdPtr, FRcvBufSize); FRcvdPtr := nil; FRcvBufSize := 0; FRcvdCnt := 0; end; inherited TriggerSessionClosed(Error); end; I'm not sure I understand why TriggerSessionClosed would want to call OnDataAvailable, but I realize there may be reasons for this. However, I think some flag should be set immediately after the line is found -- before new data arrives -- so that closing the connection does not re-enter the event. -dZ. -- 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] pop3 component not ready
Hello: If I understand correctly, you send the Quit() command after a failure and then try CheckNewMail() again? You must wait for the Quit() command to complete, it will trigger OnRequestDone with an error code. You should try something like this instead: (Mind you, this is out of the top of my head, so I can't guarantee it will compile or that its the best way; it is just intended to offer an idea on how to handle the errors.) Procedure TMailAlert.Pop3ClientRequestDone; Begin // NOTE: // ErrorCode and ReqType are params // of the OnRequestDone event. // No error, send the next cmd. If (ErrorCode <> 0) Then Begin Case ReqType Of pop3Connect : FPop.User; pop3User: FPop.Pass; pop3Pass: FPop.Uidl; // ... End; // There was an error, try to // fail gracefully. End Else Begin // If the failure was during Quit, // we need to abort to reset the // component. If (ReqType = pop3Quit) Then FPop.Abort // Otherwise, quit gracefully if // still connected. Else If (FPop.Connected) Then FPop.Quit; End; End; >--- Original Message --- >From: [EMAIL PROTECTED]:[EMAIL PROTECTED] >Sent: 12/12/2007 12:21:45 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] pop3 component not ready > >procedure TMailAlert.CheckNewMail; begin with FPop do if not Connected then begin Fbusy := true; ClearErrorMessage; Connect; end; end; as you see, the pop component is not connected when i do the connect cmd. that's the strange thing, the connection is closed but the component is not in a ready state. -- 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] pop3 component not ready
> whats the proper command to close the connection gracefully ? The command is "Quit". On a pinch, you could use "Abort", which will close the socket connection abruptly if it is opened, but "Quit" will send the "QUIT" POP3 command to the server and wait for it to close the connection. -dZ. -- DZ-Jay - [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] Simple TWSocket listener question
Hello: What I did was override DupConnected and call TriggerSessionConnected() if the current state is different than wsConnected: Procedure TClientSocket.DupConnected; Begin If (Self.State <> wsConnected) Then Self.TriggerSessionConnected(0); Inherited DupConnected; End; This seems to work and I don't see why it would be a problem. Can anybody tell if this is a bad idea? I also can't think why the component wouldn't do this itself. That way, if you assign the socket to a client object, you can still take care of it as you would a normal TWSocket client object using OnClientConnected and OnClientDisconnected to mark the lifetime of the connection. -dZ. >--- Original Message --- >From : [EMAIL PROTECTED]:[EMAIL PROTECTED] >Sent: 12/11/2007 4:10:31 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] Simple TWSocket listener question > I've noticed that when this is done, the OnSessionConnected event of the client is never triggered. I thought this was unusual as I thought that FD_CONNECT (which ultimately triggers the event) comes after FD_ACCEPT. Or am I doing something wrong? -dZ. -- 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] Simple TWSocket listener question
Hello:
I'm still getting familiar with the low level
functionality of the TWSocket underlying component,
so please excuse my question if it sounds trivial.
I'm trying to set up a simple tcp listener that
accepts a single client connection and communicates
with it. I am basing it off the TWSchat demo as it
does pretty much what I need:
- to accept a client
- to keep listening while connected
- to respond with a message when other clients
connect
The way I'm doing it (as per the demo) is to give
the accepted socket handle to the client object if it
is free in the OnSessionAvailable event:
Procedure TSrvApp.Srv_ClientAvailable(Sender:
TObject; Error: Word);
Begin
If (FCliSocket.State = wsConnected) Then Begin
// we're busy, dismiss the connection
FBusySocket.HSocket := FSrvSocket.Accept;
FBusySocket.SendStr('Server busy, try again
later.'+ #13#10);
FBusySocket.CloseDelayed;
End Else Begin
// Accept the connection
FCliSocket.HSocket := FSrvSocket.Accept;
FCliSocket.LineMode := True;
End;
End;
I've noticed that when this is done, the
OnSessionConnected event of the client is never
triggered. I thought this was unusual as I thought
that FD_CONNECT (which ultimately triggers the event)
comes after FD_ACCEPT. Or am I doing something wrong?
-dZ.
--
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] AV in TWSocketThrdServer.PutDataInSendBuffer
Quote from Arno: csDestroying is already in the states when you call DisconnectAll() from the destructor of the server's owner component. If you created the server with a nil owner, no problemo. - Then, as you say, there's no problemo, because that's exactly what I do. :) So, to make sure I understand: If I call DisconnectAll() before destroying the server component, I still need to wait and process messages to make sure all clients are disconnected *before* calling the server's destructor, or else it may never fire OnSessionClose() on them once it starts destroying, right? -dZ. -- 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] AV in TWSocketThrdServer.PutDataInSendBuffer
Quote from Arno: Not in my sources. It posts a message to tell the threads that they shall terminate. When a thread terminates clients are just ThreadDetached. Yes, you are right, sorry. Quote from Arno: I guess it's worth a trial to simply ThreadAttach all clients in the destructor after all threads terminated. .. I'm sorry, I don't mean to be obtuse, but what would that do? I was thinking I could call DisconnectAll() before calling the destructor of the thrdserver... would that help? -dZ. -- 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] AV in TWSocketThrdServer.PutDataInSendBuffer
Hello:
I was testing my application and and noticed in
the log that when I tried to destroy the
TWSocketThrdServer while it had opened connections, I
got a few (seemingly) random AVs which I traced to
the following lines in PutDataInSendBuffer method:
procedure TCustomWSocket.PutDataInSendBuffer(Data :
Pointer; Len : Integer);
var
oBuffer : TBuffer;
cWritten : Integer;
bMore : Boolean;
begin
if (Len <= 0) or (Data = nil) then
exit;
{$IFDEF COMPILER2_UP}
EnterCriticalSection(GSendBufCritSect);
try
{$ENDIF}
{ THE FOLLOWING LINE }
if FBufList.Count = 0 then begin
oBuffer := TBuffer.Create(FBufSize);
FBufList.Add(oBuffer);
end
else
oBuffer := FBufList.Last;
Inc(FBufferedByteCount, Len);
bMore := TRUE;
while bMore do begin
cWritten := oBuffer.Write(Data, Len);
if cWritten >= Len then
bMore := FALSE
else begin
Len := Len - cWritten;
Data := PChar(Data) + cWritten;
if Len < 0 then
bMore := FALSE
else begin
oBuffer := TBuffer.Create(FBufSize);
FBufList.Add(oBuffer);
end;
end;
end;
bAllSent := FALSE;
{$IFDEF COMPILER2_UP}
finally
LeaveCriticalSection(GSendBufCritSect);
end;
{$ENDIF}
end;
The full error is "[EAccessViolation] Access
violation at address 00469094 in module
'SmailQ_con.exe'. Read of address 0008"
Its hard for me to reproduce exactly, but has
anybody any idea what could be causing this?
-dZ.
--
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] ICS
Farhan, I'm posting a copy of this message to the list because I think other members can offer good help for you to migrate your application to ICS. The TWSocket component communicates with the WinSock API at the lowest levels, and therefore it may seem more complicated to deal with than other more "abstracted" components. However, this is precisely the reason it is so powerful, flexible and efficient. If I understand your question correctly, you want to send a stream of data of arbitrary length, or at least be able to send a large string without having to worry about buffer size or re-building the packets on the receiving end. You can do this quite easily by enabling "LineMode" and setting a very large number as the maximum line length (ideally, the maximum that your data can be). What this will do is make TWSocket receive all data packets and build the original string completely before triggering the OnDataAvailable event. Therefore, when the event is finally triggered, you are guaranteed to have the entire data. The only other thing you need to select an appropriate delimiter string or character that will let TWSocket know when end of the data has been received. Typically, for the higher-level Internet protocols (such as FTP, SMTP, POP3, etc), a combination of Carriage-Return and Line-Feed (#13#10) serves as the line delimiter. But for binary transfers, you may want to pick something that you can be sure to *not* exist in your data stream. It can be a single control character or a combination, as long as you can be sure it will not occur on your data. So, you set LineMode to true, LineLimit to a very high value (or the length of the data itself), and LineEnd as the end-of-data delimiter, then call SendLine() with the string you want to send: StrData := 'This is the data you want to send'; StrEnd:= #0#0; WSocket.LineMode := True; WSocket.LineLimit := 6553; // Length(StrData) + Length(StrEnd); WSocket.SendLine(StrData); Let me know if you need any more help with this. -dZ. >--- Original Message --- >From : Farhan Anwar[mailto:[EMAIL PROTECTED] >Sent : 12/5/2007 1:23:23 PM >To : [EMAIL PROTECTED] >Cc : >Subject : RE: ICS > > FARHAN ANWAR Yes Sir i have a question That will help me to convert The Project.If u can Answer then here is my question. In TSockets We can Send As Many data as we can In One line of Code.But In TWSocket We hae to Set the Buf Size,and at the receiving side we get te data in Small packets,or some thing like that.How can i assume that the data i got is the Continued Data sequence and what is the length of the actual data,or simply how can we send and receiove stream -- 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] TWSocketServer and backlog
No worries! Here's the update on this: I have *slightly* modified my application based on the suggestions and insight I received from this list. When I say "slightly" I mean "a lot", but that sounds too ominous :) First, I switched to TWSocketThrdServer without a hitch (hurray! for Arno's hard work on it). This introduced a new bottleneck: the database calls needed to be synchronized, and so it was basically the same as running on a single thread but with the additional overhead of thread creation and synchronization. The end result was that it made my server slower. Which brings me to the second change I made: I re-factored all database requests into a separate thread and completely de-coupled the other two working threads from having to perform any database access or additional management logic; they just post messages to the new thread with the data they need stored in the database. This introduce a whole new level of complexity: that of inter-thread communications and how to cope with un-received posted messages if the thread needs to abort unexpectedly (since the other threads now "send and forget" and expect the database thread to do its thing). And this led me to the final change in my application: The new database thread became the overall manager of the application: it governs all other threads, instructs them when to start and stop, and appropriately deals with anybody's impromptu demise. So now I have 3 worker threads: 1. Queue Manager: performs all database access, inter-thread management, application initialization and recovery, and overall management of the entire queue. 2. Queue Receiver: accepts incoming client connections and stores their data into the queue, then post the necessary information to the Manager, making sure state is always recoverable in case of failure. 3. Queue Dispatcher: scans periodically the queue and sends the messages via SMTP, then posts a message to the Manager announcing their result (whether success or failure) so that it can update the database record and remove the message from the queue. It also receives notifications from the Manager whenever new messages arrive of higher priority, so that it can interrupt its current scan and address those. Overall, the new design is more elegant and flexible, and still very stable; but more importantly, it is now considerably faster than before (orders of magnitude), and none of the connection issues that I was encountering are manifesting anymore. For the sake of comparisson, it now can take about 30 to 40 seconds to send 1000 messages to the Queue Server. And that's with a backlog of 50. A backlog of 5 takes a few seconds more because (at most) a handful of connections need to be retried (10061 error). A backlog of 10 succeeds without retries and takes roughly the same time. This means that it was my application design which was impeding the performance of TWSocketServer, and not an inherent issue with TWSocket itself (DOH!). System resources are limited, of course, so in my opinion our empirical analysis on the usage of the backlog is still valid: a larger number seems to affect performance negatively without any overall gain in availability, especially under heavy stress. In conclusion, as Arno and Wilfried suggested from the beginning (and as Francois has always claimed), TWSocket is fast, efficient and fully capable of handling thousands of concurrent connections, provided there are sufficient resources for it, and that no _extensive_processing_ is competing with the socket communication. How's that for an endorsement :) Thanks to all of you who offered help and suggestions. Cheers! -dZ. >--- Original Message --- >From: Hoby Smith[mailto:[EMAIL PROTECTED] >Sent: 12/5/2007 12:44:57 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TWSocketServer and backlog > >Hey DZ. Sorry, I didn't mean to drop out of this email thread. I have just been slammed for the last week and didn't have a chance to response to any of the further posts on this (they were buried in very long inbox). From what I see, Wilfried and Arno helped you out more than I would have anyway. Also, sorry I misunderstood your initial post about this. Story of my life... always coming in to the middle of a conversation confused and broke... ;) BTW, the "pocket calculator" comment was LOL... :) -- 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] Webserver only with local connections
George, I think Hoby's response is excellent, but I wanted to add a few suggestions based on my interpretation of your problem. 1. If the source address of each of the hosts that will communicate is known, then you can check for this using the GetPeerAddr method from within the SessionAvailable method of TWSocket (I believe this is exposed in HttpCli as the OnClientConnect event), and as Hoby suggested, abort the connection if the address does not match. Obviously, this will bind your application to those specific addresses, so if they ever changed you'll need to make sure to update the validation values. Also, as Hoby mentioned, you must bear in mind that the source IP address can be spoofed, so depending on the criticality or exposure of your application, you may not want to trust it. 2. Authenticate the incoming request by using one of the common mechanisms supported by HttpCli. This still means that the connection needs to be accepted, and actively rejected if it failed authentication. One last note: Under no circumstances trust any information available on the HTTP request/response header for validation or authenticity (IP address, referrer, content-type, etc.); these are very trivial to forge. For most HTTP appliations, this is normally not a problem, as long as they do not expect any of those values to contain critical information that could affect the behaviour of the system. -dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html >--- Original Message --- >From: Hoby Smith[mailto:[EMAIL PROTECTED] >Sent: 12/4/2007 12:05:56 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Webserver only with local connections > >George... Fundamentally, there are really only two ways to constrain inbound connections regarding client identification. As I am sure you are aware, keep in mind that neither TCP nor HTTP have any built in mechanisms for facilitating client identification or rejecting connections based on any rules. As a result, it is irrelevant what address / port you "listen" on, as TCP will always attempt to allow the connection initially, unless a firewall or something else between the host and server prevents the process. It is up to you then to reject any unwanted connect attempts at some point. Given this, you must address the issue in either or both of the following areas: 1. Client origin or source of connection If you wish, you may determine the client's origin and reject the connection based on that origin. The TWSocket components give you this ability at the session level. The standard TCP stack has no mechanism to do this until after the session is actually arbitrated, so by default you must accept the connect (at least partially into the cycle), then reject the connection, once you have determined that you wish to do so. So, if you wanted to constrain the source address of the client to a local or specific address only, you could provide some functionality in the OnClientConnect event that determines the connecting source address and rejects the ones you don't want, such as if it is not in the local address space. Bear in mind that the local address space could originate from the local loopback (127.0.0.1), as well as one of the local NIC addresses as well. For example, you could use, TMyHttpConnection(Client).GetPeerAddr, to get the client's address and then determine if you want to disconnect it. You would have to provide this logic and any rules as you need. Also, bear in mind that the source address can be compromised through various attacks. PPTP and other forms of tunneling attempt to prevent those kinds of issues (such as with VPNs implementations). 2. Some form of secure authentication that should be at least moderately trustable. If I understand your need correctly, you are saying that you DO want to allow connections from other IP subnets, you just want to know if they are from you or something else. To accomplish this, you need to support some form of authentication, because there is NO inherent ability in TCP or HTTP to tell you this. This is what you are really looking for. Regardless of the source of origin, you are really trying to ask the question, "Is this me or someone else"? Right? If so, the only solution is to use some form of authentication to determine this. I personally don't use HTTP much because it is so weak in this regard; in that, it has no native ability to support authentication. As a result, you must address authentication very high up the stack, on top of protocols that understand nothing about security or authentication. However, there are several mechanisms for performing authentication over HTTP. I would suggest that you look at the ICS demo app "WebServ". It appears to be handling the authentication you are looking for and should have the code examples you are lo
Re: [twsocket] TWSocket transliterating tabs to spaces (nevermind)
I noticed that it is not initialized anywhere, which means that its going to be False by default (supposedly). Perhaps compiler optimizations will cause it to be stored in a cpu register and without initialization may not be guaranteed to be 0 (false). -dZ. >--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] >Sent: 12/3/2007 4:38:28 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TWSocket transliterating tabs to spaces (nevermind) > >[EMAIL PROTECTED] wrote: > Hello: > Nevermind my last message. Too late ;-) But it should be realy made the default value. FLineEdit seems not being initialized correctly allways, at least not by the Delphi 7 compiler, maybe when Optimization is turned off ? -- Arno Garrels Like an idiot, I set > LineEdit mode to True by mistake. I made this change > inadvertently today, which explains why I didn't > notice it before. > > Sorry, > -dZ. > > >> --- Original Message --- >>> From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] >> Sent: 12/3/2007 4:09:17 PM >> To : twsocket@elists.org >> Cc : >> Subject : RE: [twsocket] TWSocket transliterating tabs to spaces (?!) >> > >Hello: > I just noticed something very bizarre: My client > application sends text data using TWSocket to a > TWSocketServer server application, and leading tabs > are transliterated into spaces when they arrive! > > I've traced a particular string all the way until > TWSocket puts it in its internal buffer to send and > it still contains a #09 char at byte position 0. > However, tracing the OnDataAvailable event of the > receiving TWSocketClient, ReceiveStr returns the same > string but now it has spaces at the beginning and no > tab character. > > I don't recall ever seeing this before. Perhaps > I'm missing an obscure setting or made a stupid > mistake? Can anybody offer any suggestions? > > -dZ. > -- 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] TWSocket transliterating tabs to spaces (?!)
Thank you for your very fast response -- even faster than my other message acknowledging my stupidity :) >> Is LineEdit turned on ? Yes, it was. DOH! Thanks, -dZ. -- 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] TWSocket transliterating tabs to spaces (nevermind)
Hello: Nevermind my last message. Like an idiot, I set LineEdit mode to True by mistake. I made this change inadvertently today, which explains why I didn't notice it before. Sorry, -dZ. >--- Original Message --- >From : [EMAIL PROTECTED]:[EMAIL PROTECTED] >Sent: 12/3/2007 4:09:17 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] TWSocket transliterating tabs to spaces (?!) > >Hello: I just noticed something very bizarre: My client application sends text data using TWSocket to a TWSocketServer server application, and leading tabs are transliterated into spaces when they arrive! I've traced a particular string all the way until TWSocket puts it in its internal buffer to send and it still contains a #09 char at byte position 0. However, tracing the OnDataAvailable event of the receiving TWSocketClient, ReceiveStr returns the same string but now it has spaces at the beginning and no tab character. I don't recall ever seeing this before. Perhaps I'm missing an obscure setting or made a stupid mistake? Can anybody offer any suggestions? -dZ. -- 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
[twsocket] TWSocket transliterating tabs to spaces (?!)
Hello: I just noticed something very bizarre: My client application sends text data using TWSocket to a TWSocketServer server application, and leading tabs are transliterated into spaces when they arrive! I've traced a particular string all the way until TWSocket puts it in its internal buffer to send and it still contains a #09 char at byte position 0. However, tracing the OnDataAvailable event of the receiving TWSocketClient, ReceiveStr returns the same string but now it has spaces at the beginning and no tab character. I don't recall ever seeing this before. Perhaps I'm missing an obscure setting or made a stupid mistake? Can anybody offer any suggestions? -dZ. -- 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] ICS wiki templates (are there any?)
Hello: I noticed that a lot of the components and their methods/properties wiki pages have basically the same layout and sections, and I was wondering (before I endeavor to start from scratch) if there was a template, or if it's just copy+paste from a previous one? -dZ. -- 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] Help with SmtpClient
Hello: The problem is on calling the Helo(): That method is "asynchroneous", meaning that it does not wait for the server's response before returning; it will eventually trigger the OnRequestDone event when the server's response arrives. However, you are using the Open() method, which already sends the HELO command itself. To fix your problem, just remove the call to Helo(), and leave Open() followed by Mail(). Open and Mail are "synchrenous" methods. The SmtpCli component, as all other ICS components, have built-in sync and async methods. The sync methods are for quick and easy development: you make the call and it will return when completed. The async methods are more advanced and require an event-driven approach to programming, similar to the style of the VCL itself. Although it is a bit more complicated, we always recommend you use the async methods, which give you more control, and help keep your application more responsive. -dZ. >--- Original Message --- >From: Victor Gooch[mailto:[EMAIL PROTECTED] >Sent: 11/30/2007 2:44:25 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] Help with SmtpClient > >I am using BCB6 with SmtpClient. My program executes Open() then Helo() with no errors but when I try to execute Mail() I get an error message that the "Component is not Ready". I have examined the property settings several times but do not see why Mail() does not work. is this a FAQ ? Are there any suggestions? thanks, Victor -- 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] Newbee writing webcam utility
Hello: You can use the HttpCli component, which implements the HTTP protocol for client applications. Check out the HttpDemo that comes with ICS for more information on how to use it. Basically, you give it the location URL, and perform a GET request. It should return the requested data, which in your case is an image file. However, being binary, it'll most likely be encoded in base64, so you'll need to decode it. I don't recall if HttpCli does this by itself (I don't think so), but it shouldn't be a problem, as you can use the MimeUtils unit that comes with ICS (in the VC32 directory), which has excellent routines for this. Once you decode it, you can store it in a file (or decode to a TFileStream) and then transfer it via FTP using the FtpCli component. -dZ. -- DZ-Jay - [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html >--- Original Message --- >From: Bob Reeves[mailto:[EMAIL PROTECTED] >Sent: 11/30/2007 1:25:53 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] Newbee writing webcam utility > >Hi Folks, Just downloaded and installed ICS in Borland C++ Builder 5, looks like it is going to be just the ticket for a little project I am getting ready to work on. Postcard will be forthcoming as soon as I can get into town and pick one up. This little project is going to be for my model airplane clubs webcam. We have a D-Link DSC-900 ordered and I have already created the web html page. What I now need to do is create is the server side app that will grab an image from the web cam and FTP it to the internet site. I think I can figure out the FTP stuff thanks to the great sample app that came with ICS, what I am not sure how to do grab the image from the camera? My understanding is the D-Link DSC-900's current image can be accessed from my local network by simply entering the URL into IE. Something like http://192.168.0.20/IMAGE.jpg I am going to need to grab this image every minute or so, rename it and FTP it up to the web site. What I need to know to get started is which ICS component will I need to use to grab the image so I can save it to the hard drive? Any tips would be appreciated, once I have the image on the drive I am fairly confident I can work out the balance of the stuff the app will need to do. The web page I created is here http://www.tulsacl.com/Webcam.html Feel free to steal the HTM code if you need a webcam page as I borrowed most of it myself from stuff I found on the net and in news groups. Thanks Bob Reeves -- 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] TWSocketServer and backlog
>--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] > >> You can exchange data between threads the most easy is by posting a >> message where a pointer to the data is in WParam argument. The >> pointer can be freed in the custom message handler. > That's indeed the fastest way since the thread must not wait. However, if the main thread notified the slave threads to quit, the last thread that quits may post messages (before receiving the WM_QUIT message) to the first one and fail, which will cause the memory in the message to not be freed (until the application finally quits). I don't know if this is a real concern, though. > 1 - Stressing a server with 100 connection attempts per second is most > likely not a real world scenario, except upon DoS attacks. I agree. However, this is very easily done by a brain-dead developer using my queue client class in a simple 'for' loop to send a lot of messages at once, say, an announcement to all our customers. I would like to prevent this as much as possible by improving connection acceptance speed on the server, or else I'll have to cripple the client somehow. Do not underestimate the tenacity of morons. :) > 2 - Run your stress tester against IIS or other servers, I found that > they were not able to accept more clients per second than my server. I'm sure this is true. I am able to avoid the whole issue by responsibly designing the client application: send the next connection request after the first one triggers OnSessionConnected, or connecting only a few clients at a time, then pause until they are done. This not only improves performance of the server, but it prevents an inadvertent DoS attack from an application that needs to send lots of messages at once. > 3 - I played with different designs. Which would you consider to work best? > The goal is to accept clients as fast as possible, once they are > connected it won't hurt to let them wait some milliseconds. This is indeed my goal. Would it make sense to have a pool of listening sockets in a separate (single) thread that will post a message to the (single) working thread with the socket handle? That way the connections can be established quickly, and my server can continue doing its processing within a single thread so that I don't have to redesign it right now. -dZ. >Sent: 11/29/2007 1:52:38 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TWSocketServer and backlog > >DZ-Jay wrote: > On Nov 29, 2007, at 06:10, Wilfried Mestdagh wrote: > >> Hello DZ-Jay, >> >> So conclusion is that increasing the backlog does: >>- decrease the performance for accepting connections >>- decrease the overall performance of the application > > This seems to be the conclusion of mine and Huby's tests. Strange, I never noticed something like that. > Perhaps I should run the TWSocketServer on its own thread, and post > messages from the clients to the queue manager thread to do the work? > Although this seems too complex and expensive. It almost looks like > each client should run on its own thread... :( I'm that sure: 1 - Stressing a server with 100 connection attempts per second is most likely not a real world scenario, except upon DoS attacks. 2 - Run your stress tester against IIS or other servers, I found that they were not able to accept more clients per second than my server. 3 - I played with different designs. a) Listening sockets in one thread, client sockets in another thread(s). This introduces a new problem, clients are accepted very fast, however the listening thread must synchronize with the client thread(s) which may take longer than with current TWSocketServer, I worked around by posting just the socket handle to the thread which was fast, however also rather complicated to handle all the client stuff/pool in the threads. b) Listening sockets in one thread, one thread per client. AFAIR without a thread pool accepting clients was slower than with TWSocketServer. c) I even hacked together a server that used M$ overlapped sockets, this was a rather disapointing discourse since performance was the same as with (a). The goal is to accept clients as fast as possible, once they are connected it won't hurt to let them wait some milliseconds. Before you rewrite your application I suggest you code some test apps. with different designs and compare their performance. -- Arno Garrels > > dZ. > > -- > DZ-Jay [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our websit
Re: [twsocket] TWSocketServer and backlog
Hello: Thank you for your very informative response. I was performing some tests on my server application by continually increasing the backlog value with some mixed results, which seem to coincide with your empirical analysis. I kept increasing the backlog value up until I reached 1000, but to my surprise, I noticed that the connections started failing after about 230 requests, out of 1000 clients. These were the first 230 requests, so the backlog queue was significantly less than its maximum. I also thought I noticed that the server was taking longer to respond, but didn't think much of it at the time. However, after reading your post I decided to try once again with a backlog of 5, and set a retry loop every time a connection failed. As expected, the connections started failing almost immediately after the test started. But much to my surprise, the connections were handled quicker -- sometimes orders of magnitude faster than before! As a reference, using my localhost as the server and client, with a test application spawning 1000 clients to connect one right after the other, and re-trying if they failed, it took about 5 to 7 minutes to process the entire lot; while it only took about 2 minutes to process with a backlog of 5. The test with a backlog limit of 5 retried much more times, of course, but when connections were established, they were processed faster. Still, it seems to me that TWSocketServer is taking too long to process incoming connections, as many connections can be queued in the backlog while its instantiating the client and dupping the socket. Any thoughts on this? -dZ. >--- Original Message --- >From: Hoby Smith[mailto:[EMAIL PROTECTED] >Sent: 11/28/2007 5:31:09 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TWSocketServer and backlog > >FYI... I ran into an issue with some test code I wrote a few months ago, which related to the backlog setting, as well as the annoying issue with Winsock running out of local ports. In my test, I was attempting to see how many connections could be handled by a particular process over a period of time. I believe my results showed that increasing this value can have a very negative effect on performance. Basically, the issue is inherent in how the TCP stack is implemented, not in how a particular app services the stack. I found that surpassing a particular connection rate threshold would result in an exponential gain in processing time on the listening stack. Meaning, the TCP stack performance decreases dramatically as you increase the number of pending connections, when the listening socket is receiving a high rate of connection requests. My assumption is that this is due to the increased overhead in managing the backlog queue. Given this, I made two observations, which may be wrong, but made sense to me. First, this is why the Winsock default is 5. I imagine that the Winsock stack implementation was designed with the perspective that if the backlog is actually filling up enough to reach 5 or more, then something is wrong. Probably, a couple more might be ok, but my results showed that as you increased this value under heavy load, your connection rate was very unpredictable, as well as instable (lots of failed connects). For the TCP/IP stack to be effective, it must be responsive enough to handle the low level connection requests in a timely fashion. If not, then you have a major low level servicing problem or the machine is seriously overloaded with TCP requests. In which case, you want to get connection errors, rather than an overloaded backlog scenario. Second, increasing this value surely creates a greater DOS attack surface, making you more vulnerable to bursts of socket open requests, and surely would make the effects of such an attack even worse. This might also be why the Winsock default is 5. However, as I personally don't think that there is really a practical solution to a well designed DOS attack, then this might not really be relevant. Nonetheless, it might be something you need to consider. So, given that, I personally don't recommend increasing the value. If your app can't service the stack with a backlog setting close to 5, then your system is just overloaded or not responsive for some reason. Anyway, that is what I determined from my testing results. If anyone has found to the contrary, please feel free to correct me... :) -Original Message- -- 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] ASyncReceive and wsoNoReceiveLoop
Hello: I'm not sure if this is related to your problem, but I had a similar incident in the past, and it turned out to be an unchecked buffer in my OnDataAvailable event handler which caused an overflow, which led to the TWSocket component not realizing that the buffer had been emptied and triggering the event again. Check to make sure that you are not overwriting some data in your event handler due to a buffer overflow. -dZ. >--- Original Message --- >From: Jake Traynham[mailto:[EMAIL PROTECTED] >Sent: 11/28/2007 4:24:15 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] ASyncReceive and wsoNoReceiveLoop > >Hello all, I'm using ICS version 6.06 with Turbo C++ Explorer 2006. I had been fighting a problem where my DataAvailable event was being called twice as many times (minus 1) as actually needed. Since I've been using the ICS components for many, many years now, I obviously started looking to see if somehow I was calling ProcessMessages again within the DataAvailable. I couldn't find any where that was true. I finally looked into the TWSocket sources to see where DataAvailable was triggered from and to see if anything there would make it act this way. This is when I saw this wsoNoReceiveLoop thing (which is apparently off by default). Turning that option on made my problem go away. My question is, what am I missing? Either I don't understand why you would *want* ASyncReceive to loop, or maybe I'm not correctly reading in the data? The component I'm working on receives large amounts of data from a server in successive blocks. From what I observed, my DataAvailable event was being called twice minus one more times than it needed to be. For example, if the server sent 6 blocks of data, my DataAvailable event would get called 6 times to receive all of the data, then get called 5 more times. In the 5 extra times, my code would attempt to do a Receive, which would return -1 along with the "Would Block" winsock error. So, it seems that for every time ASyncReceive looped, there would still be a message (FD_Read??) being put in the queue to call it again, which would call my DataAvailable event again, but there wouldn't be any data to read because ASyncReceive had already looped to get all the data. Again, am I missing something here? Should there have only been one FD_Read in the queue initially which would start the ASyncReceive loop but some how the queue is getting corrupted (by some call to ProcessMessages maybe) causing it to respond to the FD_Read more than once. Or should there be an FD_Read for every block of data coming from the server, and if that's the case, why does ASyncReceive loop? Because if there is an FD_Read for every block of data, then ASyncReceive and any DataAvailable events would be called multiple times. Help! :) Jake -- Jake Traynham Owner, CNS Plug-ins http://www.cnsplug-ins.com/ -- 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] I need some help understanding TWsocket states
Pablo, Are you having more problems? P.S. Puedes comunicarte conmigo directamente si necesitas ayuda en español. Translation: You can contact me directly if you require help in Spanish. -dZ. >--- Original Message --- >From: Pablo Harguindey[mailto:[EMAIL PROTECTED] >Sent: 11/28/2007 3:22:18 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] I need some help understanding TWsocket states > >*help -- 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] I need some help understanding TWsocket states
>--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] > > OnSessionAvailable is called only on listening TWSockets, > as I read the post it deals with a client (connecting party). Thanks, Arno. You are right; I misread his message but didn't realize this after sending my response. I then explained the same thing, just like you and Wilfried did, so he's sure to understand it now :) Its nice to have a mailing list where you can get many people addressing the same questions :) -dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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] TWSocketServer and backlog
Hello: The problem with retrying is that it is not the same as a "server full" error when the maximum number of clients is reached; 100061 is essentially a "port not open" error, which is the same error you would get if the server is not running. So there is no real way to know that the listener is currently busy and the backlog full, or if the server is listening on a different port or disabled completely. I will certainly increase the backlog on my server, but will also consider building a number of retries in the connection routine of the client class. Thanks for the help. -dZ. >--- Original Message --- >From: Wilfried Mestdagh[mailto:[EMAIL PROTECTED] >Sent: 11/28/2007 2:26:49 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TWSocketServer and backlog > >Hello dz, a client application should do at least a few (or infinity) retry's if connection fails. so normally not needed to increase it. On the other hand it does no harm to increase it. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Wednesday, November 28, 2007, 18:27, [EMAIL PROTECTED] wrote: > Hello: > While stress-testing my application, I noticed > that I am able to send substantially many more > connections in the time it takes the TWSocketServer > to handle the incomming requests, causing the default > backlog to fill up quickly. Obviously, I can > increase the number, but seeing that the default is 5 > (which seems rather low to me), I'm thinking that > perhaps there may be a concern in setting this too high. > Does anybody know what I should take into > consideration before changing this value, and if > there are any concerns with it being too high? > Thanks, > -dZ. -- 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] TWSocketServer and backlog
I would also imagine that testing this within the local host will also affect the backlog, as you are establishing both sides of the socket within the same host, limiting the resources, no? -dZ. >--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] >Sent: 11/28/2007 2:22:46 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TWSocketServer and backlog > >Paul wrote: > I always use 500, no problems yet But the ListenbacklogQueue is limited in size depending on the OS (cannot recall the values, however it's far less then 500, AFAIR). The more "blocking" the server behaves the earlier you get 10061 back from a connect. Simple test is with TcpSrv Demo, with logging to the memo enabled I get the first error 10061 after 100-200 connects (10ms intervals). Turning off logging to memo establishes several thousand connections without any error easily. -- Arno Garrels > > Paul > > > - Original Message - > From: <[EMAIL PROTECTED]> > To: > Sent: Wednesday, November 28, 2007 6:27 PM > Subject: [twsocket] TWSocketServer and backlog > > >> Hello: >>While stress-testing my application, I noticed >> that I am able to send substantially many more >> connections in the time it takes the TWSocketServer >> to handle the incomming requests, causing the default >> backlog to fill up quickly. Obviously, I can >> increase the number, but seeing that the default is 5 >> (which seems rather low to me), I'm thinking that >> perhaps there may be a concern in setting this too high. >> >>Does anybody know what I should take into >> consideration before changing this value, and if >> there are any concerns with it being too high? >> >>Thanks, >>-dZ. >> >> -- >> 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] I need some help understanding TWsocket states
Hello: OnSessionAvailable is triggered when an incoming connection is about to be established, as soon as the request is received, but before the socket is properly opened. OnSessionConnected is triggered right after the connection, either incoming or outgoing, is properly established and state is changed to wsConnected. If you're not listening on the port, then that could explain why OnSessioinAvailable is not being triggered. You want to handle OnSessionConnected instead. -dZ. >--- Original Message --- >From: Pete Williams[mailto:[EMAIL PROTECTED] >Sent: 11/28/2007 2:09:51 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] I need some help understanding TWsocket states > >I don't mind checking simple stuff. I'm desperate, as I have a deadline for Saturday! It is definately connected & hooked-up. Nothing is over-writing it. [EMAIL PROTECTED] wrote: > Hello: >This may sound stupid, but could you verify that > the OnSessionAvailable event is actually wired > (assigned to the property)? It seems strange that it > is not called, yet OnDataSent is. > >Also, what happens when you try to send a second > time (or does it even try)? Do you get a "Component > already connected" error or something like that? > >If your burst messages are short as your example > implies, then there is really no reason to do this on > a separate thread; it will actually be slower to > spawn a new thread and execute it than to just > re-connect and call SendStr. > > -dZ. > > -- 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] TWSocketServer and backlog
>--- Original Message --- >From: Paul[mailto:[EMAIL PROTECTED] > > I always use 500, no problems yet Thanks for the quick reply. Then, is there a particular reason why it defaults to 5? It seems too low for all but the most trivial applications (given that spawning the client object and dupping the socket seems to take a relatively long time). -dZ. -- 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] I need some help understanding TWsocket states
Hello: This may sound stupid, but could you verify that the OnSessionAvailable event is actually wired (assigned to the property)? It seems strange that it is not called, yet OnDataSent is. Also, what happens when you try to send a second time (or does it even try)? Do you get a "Component already connected" error or something like that? If your burst messages are short as your example implies, then there is really no reason to do this on a separate thread; it will actually be slower to spawn a new thread and execute it than to just re-connect and call SendStr. -dZ. >--- Original Message --- >From: Pete Williams[mailto:[EMAIL PROTECTED] >Sent: 11/28/2007 1:49:27 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] I need some help understanding TWsocket states > >Thank you to the two people who replied. I got really good advice which I followed and this seems to have given me a working server, but I still have client problems. - I created a message-pump in a distinct thread for the DLL server, as advised. - Both client and server were changed to async programming style, and this worked for the server. I have another problem though, which seems stange, and may be related to timing (or something). My client wants to sometimes connect to the server, send a few lines of data, and then disconnect. When I want to send data this is what I do procedure sendData(asMessage: string); begin mystringlist.add(asMessage); if mytwsocket.state <> wsConnected then begin mytwsocket.addr := '127.0.0.1'; // client and server are on same machine mytwsocket.port := '17072'; mytwsocket.connect(); end; end; Then I have handlers for OnSessionAvailable and OnDataSent. OnSessionAvailable doesn't seem to get called ever. In OnDataSent I do this begin if mystringlist.count > 0 then begin mytwsocket.sendStr(mystringlist[0]+#$D#$A); mystringlist.delete(0); // we've sent this one end else begin mytwsocket.close(); // no more data to send, so close end; end; Here's what I've observed. The client can send once, and that's it. I can't send twice. However, if I put a breakpoint at the end of the function that connects to the server,it works - almost like there is some kind of timing issue. I'm working on Windows 2003. Should I use threads for my clients as well? Any advice is greatly received. Wilfried Mestdagh wrote: > Hello Pete, > > >> if myclient.state <> wsConnected then >> begin >> myclient.connect; >> loop for 5 seconds begin >> > > You have to think async. TWSocket uses events. think on events as a > OnClick event of a butten. You don't write loops to wait until a user > click a button. So you have to change to: > >MyClient.Connect; // that's all > > and in the OnSessionAvailable event you start do >TWSocket(Sender).sendstr(thedatastring); > > >>myclient.processMessages; >> > > General a very bad idea to call the message pump yourself. > > >> myclient.close(); >> > > If your client has send all the data then you still dont know if the > other end has received an handled the data. if you design your proto > yourself then the receiver can close. if you dont then call > ShutDown(1); > > >> myserver.OnsessionAvailable >> begin >> myserversocket.dup(myserversocket.accept()); >> end; >> > > Better to use TWSocketSer4ver. > > --- > Rgds, Wilfried [TeamICS] > http://www.overbyte.be/eng/overbyte/teamics.html > http://www.mestdagh.biz > > Monday, November 26, 2007, 18:58, Pete Williams wrote: > > >> Hello again >> > > >> I'm trying to write a very simple client/server socket application using >> TWSocket. However, I think I may not understand the use of states correctly. >> > > >> What I want is for the client to connect to the server, send some data, >> and then disconnect. If it has more data to send, I want it to connect >> again and repeat the process. >> > > >> Here's what is happening at the moment. The client can connect to the >> server and successfully send as much data as it chooses. However, once >> it disconnects it can't reconnect. >> > > >> The code on the client is broadly thus (using a pseudo code): >> > > >> if myclient.state <> wsConnected then >> begin >> myclient.connect; >> loop for 5 seconds begin >>myclient.processMessages; >>if myclient.state
[twsocket] TWSocketServer and backlog
Hello: While stress-testing my application, I noticed that I am able to send substantially many more connections in the time it takes the TWSocketServer to handle the incomming requests, causing the default backlog to fill up quickly. Obviously, I can increase the number, but seeing that the default is 5 (which seems rather low to me), I'm thinking that perhaps there may be a concern in setting this too high. Does anybody know what I should take into consideration before changing this value, and if there are any concerns with it being too high? Thanks, -dZ. -- 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] Design isue
Hello: To elaborate a little on what Wilfried said: Imagine your application running in a typical message pump: // Imagine this is the main loop of your app: Procedure TMyApp.Run() Begin While (ThereIsStuffToDo) Do Begin DoStuff(); Application.ProcessMessages(); End; End; Your application does its thing in the DoStuff() method, and all standard house-keeping stuff is done in ProcessMessages: button clicks, window redrawing, component events, TCP/IP transmissions, etc. So, as long as DoStuff() doesn't take too long, your application remains responsive because all Windows messages are processed quickly. But when DoStuff() takes too long, *nothing* else is happening. That is, all other application and environment events (including user input and network communications) have to wait until it returns. This is basically how VCL appliations work. In the case of ICS, network communications is handled in a series of Windows messages and events that are triggered when the messages are pumped from the queue. If one of these events, say, OnRequestDone, executes an event handler in your application that takes too long, the rest of the communications will have to wait until that event handler returns. In such cases, it is better to use a separate thread to do the long-running process so that your application can continue its work normally without blocking. Why not use threads from the beginning? Well, because it is expensive and difficult. It is expensive because the operating system incurs a performance and resource cost every time it has to instantiate a new thread and allocate resources for it. It is difficult because, since they run concurrently, they require special attention when implemented, and communications between threads needs to be synchronized. I hope this helps, cheers! -dZ. -- DZ-Jay [Team ICS] http://www.overbyte.be/eng/overbyte/teamics.html >--- Original Message --- >From: Wilfried Mestdagh[mailto:[EMAIL PROTECTED] >Sent: 11/26/2007 1:31:50 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Design isue > >Hello Albert, You only need a threaded approach if you have to run very long code, meaning if your code (for example to parse incoming data, or to get data that need to be sent or so) is long (so blocking). when you write code in non threading design, the time your code is executing nothing else will happen, meaning no data is sent or received. it only will happen when your code end, that is when your application enters the message pump. hope this is somewhat clear. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Monday, November 26, 2007, 15:19, A Drent wrote: > Until now I alway build our applications using 'normal' sockets. Currently > I've got an application server build which is running well for years now. > Now I've modified the server so it is able to process soap messages. The > soap messages are send by the webserver to the application server on another > engine, parsed and executed and result is sent back. So far so good. But I > wonder, when do I have to use a threaded approach. 'Long' and 'blocking' as > said in the ics sample is very vague for me. I ask this because of a > possible near redesign of the server. > Albert Drent > University of Groningen -- 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] SOAP with httpcli??
Hello: HttpCli (any any other HTTP client) can provide the transport for SOAP transactions. However, parsing the requests and performing actions based on SOAP transaction state is up to your application: The HttpCli will only send and receive the SOAP messages without making any sense of it. This is an important distinction: HttpCli will not offer any SOAP protocol facilities, just the underlying HTTP transport of the messages. -dZ. >--- Original Message --- >From: Ulrike Foeken[mailto:[EMAIL PROTECTED] >Sent: 11/19/2007 10:21:57 AM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] SOAP with httpcli?? > >Hello everybody, Is it possible to send a SOAP request using the THttpCli component? Or is there any other possibility using ICS. We are still using Delphi 5. Kind regards Ulli E-Mail: [EMAIL PROTECTED] ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- 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] http://www.overbyte.be/
I get the following message: Maintenance mode Cette machine windows 2000 vient d'etre victime d'une mise a jour microsoft corrompue la reinstallation des backups ne résout rien nous avons mis ce serveur apache provisoire pour vous informer de l'évolution nous réinstallons les sites un à un il est probable que tout ce qui est composants Micro$oft : ftp, odbc, access, asp ne marchera pas avant une longue huit de réinstallation La page que vous voyez pour l'instant est peut etre ancienne, n'oubliez pas de rafraichir et faire F5 dans votre navigateur pour voir les nouveaux contenus -dZ. >--- Original Message --- >From: Angus Robertson - Magenta Systems Ltd[mailto:[EMAIL PROTECTED] >Sent: 11/15/2007 1:08:43 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] http://www.overbyte.be/ > >The web site has not been responding this afternoon, and now shows a page about 'Dalis SCRL'. 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 -- 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] TWSocketThrdServer
Anne, Check out the TcpSrv demo: it shows how to use TWSocketServer in a single thread with multiple clients. You can validate the data in the OnDataAvailable event, which will be triggered whenever there is data in the buffer -- or if you use LineMode, whenever the end-of-line sequence is received by the server, and the entire line string is available. -dZ. >--- Original Message --- >From: Ana Onarres[mailto:[EMAIL PROTECTED] >Sent: 10/19/2007 11:35:49 AM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TWSocketThrdServer > > I like this idea, the more simply, better. I have seen other examples. For me, i would have to create my TWSocketClient, but without thread, and in it, put the code for validating data. With this, i would have sufficient? I believe that i begin to understand. Thans for your help. Regards. Ana. > From: [EMAIL PROTECTED]> To: twsocket@elists.org> Date: Fri, 19 Oct 2007 09:07:53 -0400> Subject: Re: [twsocket] TWSocketThrdServer> > QUOTE: Angus> None of these applications use threads, they are> simply unnecessary for> most ICS applications, and cause major development> complications in> something that should be essentially simple and reliable.> END.> > I completely agree with Angus, and I learned it the> "hard way", but encountering the same complexity that> you are seeing right now. Once I switched to> TWSocketServer (using a single thread> implementation), everything simplified, yet I can> work with multiple clients in an event-driven model.> > I personally suggest you try TWSocketServer in a> single-threaded model, and if in the future you feel> it is absolutely necessary to use multiple threads> for the clients, then you can switch it to> TWSocketThrdServer.> > -dZ.> > > -- > To unsubscribe or change your settings for TWSocket mailing list> please goto http://www.elists.org/mailman/listinfo/twsocket> Visit our website at http://www.overbyte.be _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer
QUOTE: Angus None of these applications use threads, they are simply unnecessary for most ICS applications, and cause major development complications in something that should be essentially simple and reliable. END. I completely agree with Angus, and I learned it the "hard way", but encountering the same complexity that you are seeing right now. Once I switched to TWSocketServer (using a single thread implementation), everything simplified, yet I can work with multiple clients in an event-driven model. I personally suggest you try TWSocketServer in a single-threaded model, and if in the future you feel it is absolutely necessary to use multiple threads for the clients, then you can switch it to TWSocketThrdServer. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] [OT] Testing...
#> HELLO WORLD. Is the list working...? Please ignore this message. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] [OT] TWSocketServer Client.Shutdown(1) does not destroy it
>> Since I solved my own problem, and it has nothing to do with TWSocket, this message is not Off Topic. Sorry, that was supposed to say "this message is *now* Off Topic." -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer Client.Shutdown(1) does not destroy it
I believe I solved it: It turns out that my
application was intercepting the WM_CLIENT_CLOSED
message mistakenly.
My application use TWSocketServer within a worker
thread, and this worker thread has a custom message
dispatcher so that it can process messages sent to
the thread without a hidden window. The problem was
that I forgot to check if the Msg.HWND property was 0
before calling the custom dispatcher.
Since I solved my own problem, and it has nothing
to do with TWSocket, this message is not Off Topic.
-dZ.
>--- Original Message ---
>From : [EMAIL PROTECTED]:[EMAIL PROTECTED]
>Sent: 10/17/2007 2:36:00 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] TWSocketServer
Client.Shutdown(1) does not destroy it
>
>Hello:
Its worse... I also noticed that
TWSocketClient.TriggerSessionClosed() is triggered by
the client, but the message posted is never received
by the server. This happens even then the client
drops the connection. So, for some reason, the
clients are never destroyed.
I'm sure that its something to do with my code,
but can anybody offer some suggestions as to what may
cause this behaviour?
Thanks,
-dZ.
>--- Original Message ---
>From : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
>Sent: 10/17/2007 2:06:48 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: [twsocket] TWSocketServer
Client.Shutdown(1) does not destroy it
>
>Hello:
I just started noticing this behaviour today, and
I seem to recall it working differently: When
handling the OnClientDataAvailable event, if I
determine that the client needs to be disconnected, I
call (Sender As TMyClient).Shutdown(1). The
connection is dropped fine, but the client object is
never freed until the server shuts down completely.
Here's a sample of my code:
Procedure TMyServer.ClientDataAvailable(Sender:
TObject; Error: Word);
Begin
With (Sender As TMyClient) Do Begin
If (SomethingBadHappened) Then Begin
SendLine('Error!');
Shutdown(1);
End;
End;
End;
I call Shutdown(1) so that the connection is dropped
gracefully and the error response is received by the
client. I don't recall changing this recently, so
I'm confused as to why it would have been destroying
the client before and not now (I may have changed
some of the default properties, though I don't recall
anything pertinent to this issue). Perhaps there's
an even better way?
Thanks for the help,
-dZ.
--
To unsubscribe or change your settings for TWSocket
mailing list
please goto
http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketServer Client.Shutdown(1) does not destroy it
Hello:
Its worse... I also noticed that
TWSocketClient.TriggerSessionClosed() is triggered by
the client, but the message posted is never received
by the server. This happens even then the client
drops the connection. So, for some reason, the
clients are never destroyed.
I'm sure that its something to do with my code,
but can anybody offer some suggestions as to what may
cause this behaviour?
Thanks,
-dZ.
>--- Original Message ---
>From : [EMAIL PROTECTED]:[EMAIL PROTECTED]
>Sent: 10/17/2007 2:06:48 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: [twsocket] TWSocketServer
Client.Shutdown(1) does not destroy it
>
>Hello:
I just started noticing this behaviour today, and
I seem to recall it working differently: When
handling the OnClientDataAvailable event, if I
determine that the client needs to be disconnected, I
call (Sender As TMyClient).Shutdown(1). The
connection is dropped fine, but the client object is
never freed until the server shuts down completely.
Here's a sample of my code:
Procedure TMyServer.ClientDataAvailable(Sender:
TObject; Error: Word);
Begin
With (Sender As TMyClient) Do Begin
If (SomethingBadHappened) Then Begin
SendLine('Error!');
Shutdown(1);
End;
End;
End;
I call Shutdown(1) so that the connection is dropped
gracefully and the error response is received by the
client. I don't recall changing this recently, so
I'm confused as to why it would have been destroying
the client before and not now (I may have changed
some of the default properties, though I don't recall
anything pertinent to this issue). Perhaps there's
an even better way?
Thanks for the help,
-dZ.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
[twsocket] TWSocketServer Client.Shutdown(1) does not destroy it
Hello:
I just started noticing this behaviour today, and
I seem to recall it working differently: When
handling the OnClientDataAvailable event, if I
determine that the client needs to be disconnected, I
call (Sender As TMyClient).Shutdown(1). The
connection is dropped fine, but the client object is
never freed until the server shuts down completely.
Here's a sample of my code:
Procedure TMyServer.ClientDataAvailable(Sender:
TObject; Error: Word);
Begin
With (Sender As TMyClient) Do Begin
If (SomethingBadHappened) Then Begin
SendLine('Error!');
Shutdown(1);
End;
End;
End;
I call Shutdown(1) so that the connection is dropped
gracefully and the error response is received by the
client. I don't recall changing this recently, so
I'm confused as to why it would have been destroying
the client before and not now (I may have changed
some of the default properties, though I don't recall
anything pertinent to this issue). Perhaps there's
an even better way?
Thanks for the help,
-dZ.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer
QUOTE: Anne What difference is between to use TWSocketThrdServer and use TWSocketServer with ClientThread? Which is better for me? END. TWSocketThrdServer spawns a new thread for each incoming client (or a new thread after the maximum amount of clients per threads has been reached). TWSocketServer handles all clients within the same thread in an asynchroneous, event-driven way. Both handle multiple clients at the same time, the difference is the thread model. If you use the multi-threaded version, keep in mind that development and debugging is substantially more complex because of thread-safety and synchronization issues. Also, keep in mind that spawning new threads is a resource-expensive process. Because of this, it is always recommended that you use the single-threaded approach unless you *absolutely need* to use multiple threads. As I have discovered recently on this list while discussing this topic, if you are not sure that you *absolutely need* to use multiple threads, then chances are you don't. TWSocketServer is able to handle many hundreds of concurrent clients in an efficient way, and its optimized for high-performance. However, if your clients have to do very intense or long processing with the data, this may prevent the other clients from processing data, so you may need to look into the multi-threaded approach. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Over TWSocketServe
>> Very thanks. I will see this. I'm sorry, I gave the wrong demo names. The multi-threaded example applications are ThrdSrv, ThrdSrvV2, and ThrdSrvV3 (the last one using TWSocketThrdServer). The single-threaded one is TcpSrv. They are in the "Internet" directory in the ICS distribution. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] TWSocketServer friendly notice when disconnecting (was TWSocketThrdServer...)
Hello:
Ok, now that I'm switching to TWSocketServer, my
original question stands. Since all clients will run
within the same thread context, then would it be safe
to send the disconnect notice like Wilfried
originally suggested? For example:
Procedure WorkerThread.Execute;
Begin
_InitializeSrv(); // create
Try
Srv.MessageLoop();
Finally
Try
// Should this be Shutdown(1)?
Srv.Close(); // Stop listening...
For n := 0 to (Srv.ClientCount - 1) Do Begin
Srv.Clients[n].SendStr('bye'#13#10);
// do we need this? or should we
// wait until Srv.Free below?
Srv.Clients[n].ShutDown(1);
End;
Finally
Srv.Free;
End;
End;
End;
Thanks!
-dZ.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer friendly notice whendisconnecting.
Hello: Although impressive, that type of performance is out of the scope of my application, which won't be handling more than 100 (but mostly dozens) connections at a time. I guess TWSocketServer is the way to go for me. Thank you all for the help, -dZ. >--- Original Message --- >From: Fastream Technologies[mailto:[EMAIL PROTECTED] >Sent: 10/11/2007 10:08:16 AM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TWSocketThrdServer friendly notice whendisconnecting. > >I test my ICS-based MT proxy with 20k connections on our dual-core system. It performs 2GBps, local-to-local. So that's one CPU performance basically since the tester also uses CPU! I would not imagine such performance with single thread. Best Regards, SZ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer friendly notice whendisconnecting.
--- QUOTE: SZ If you do not want the ability to use multi-cores for communication threads, then async is the way to go. But IMO, it is an ill design since chipmakers are talking about 64-core CPUs and 10Gbps networks. --- END. Thanks, SZ. At this point I'm not so much concerned about complexity (although, of course, that is a concern), but more about performance and efficiency. I know that the arguments are always against multiple threads because they are harder to debug and synchronize, which is a very valid argument, and one that's biting me in the ass right now, but is that at the cost of a perceivable performance hit? Or is the async component not only simpler to use, but just as fast (or at least not significantly slower)? -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer friendly notice whendisconnecting.
--- QUOTE: Arno Garrels This is untested code. Also FThreadList has to be made public. Note that OnMessage would fire in different thread contexts but a single handler for all is fine. Hope this helps. --- END. I'll look into it. --- QUOTE: Arno Garrels I think it isn't very fast, I tested once with some stress clients and many concurrent connections successfully over many hours until that point it looked stable. In any case I won't use multi-threading if not absolutely necessary, simply because it's easier to code and to debug. TWSocketServer can handle many hundreds of concurrent connections in a single thread. --- END. Then I'm wondering if I should use TWSocketServer instead. Pardon my ignorance, as I haven't used the server components before and generally ignore any messages about them on this list, but would you (or Francois) say that its performance is good while handling potentially hundreds of concurrent connections? In actually, I don't expect my service application to serve more than 100 to 200 concurrent connections (and that's in an extreme case, perhaps once a month for a few hours). Thanks for all your help. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] TWSocketThrdServer friendly notice when disconnecting.
Hello: I've noticed that when I use Shutdown(SD_BOTH), DisconnectAll(), or Free, all clients are disconnected gracefully. However, I was wondering if there is a way to intercept that the server is shutting down, so that I can send a "Server is shutting down. Connection closed." message before closing. I guess I could loop through the collection of connected clients and send them a message, but I was wondering if there was a better way. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ICS on SourceForge, which license is best ?
> Indeed it looks very close to my usual license. > Any known drawback with this license ? Not that I know of, nor that I can see. It seems very close to the MIT license, except that the MIT license does not provide for the clear distinction of modifications from the original work -- which, in my opinion, is also the main point of your license. Here's a discussion I found on the license when the author was submitting it for approval by the Open Source Initiative: http://www.mail-archive.com/[EMAIL PROTECTED]/msg07630.html A quick Google search appears to show that the license is popular. And as far as I know, it is very common in academic research institutions. I also found version 2.0 of the license, which is based on the Apache license (again, adding the provision for distinction of derivative works). Its basically the same thing but with more legal-speak. I am not a lawyer, so I cannot tell whether any of that verbiage is actually necessary, but it seems to be in many software licenses nowadays, and perhaps that was the intention. However, it seems to mostly protect against patent lawsuits, which I understand would be an issue to a research institution. "Educational Community License, Version 2.0" http://www.opensource.org/licenses/ecl2.php -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using SourceForge for ICS ?
>> What are the requirement for such a server ? Not much. 1. Enough disk space to hold the growing repository 2. Connected to the Internet (hopefully with a firewall :) 3. Apache (to allow for web-based repository access, which is easier to maintain) Here's a link with a discussion on the subject: http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=330941 -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ICS on SourceForge, which license is best ?
So far, the closest thing to your "PostcardWare" License that I have found is this: The Educational Community License http://www.opensource.org/licenses/ecl1.php It grants all the same rights that your license does, and has a provision to prevent confusion between derivative works and the original (i.e. modified versions cannot be claimed to be the original). The only thing missing is the postcard condition :) -dZ. >--- Original Message --- >From: Francois PIETTE[mailto:[EMAIL PROTECTED] >Sent: 10/8/2007 2:59:47 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] ICS on SourceForge, which license is best ? > >I would like to have your opinion about which license I should select at SourceForge ( http://www.opensource.org/licenses/category ). I have not much time to read all possible licenses. You all know the current license displayed in each source file (see below for reminder). I would like to stay as close as possible to this simple license. Basically, I want to preserve my intellectual property while granting anyone to use and redistribute ICS source code, including in commercial applications and royalty free. Legal issues: Copyright (C) 1996-2007 by François PIETTE Rue de Grady 24, 4053 Embourg, Belgium. Fax: +32-4-365.74.56 <[EMAIL PROTECTED]> This software is provided 'as-is', without any express or implied warranty. In no event will the author be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented, you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. 4. You must register this software by sending a picture postcard to the author. Use a nice stamp and mention your name, street address, EMail address and any comment you like to say. -- [EMAIL PROTECTED] 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://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using SourceForge for ICS ?
--QUOTE: Arno Garrels It's the latter, however the point when V6 has been split from the common base is already some years back and hard to restore. There will be no new features in V5 so merging between V5 and V6 is most likely not required. Also revision numbers are incremented for the entire project/repository. But I could very well live with both in the same repository as well, locally I also treat them as two different projects. -- END. Ok, I understand. I was thinking that perhaps code fixes done to V6 may need to be merged with V5 for maintenance and legacy support, but I'm not sure if that will be case since the code may be so much different. About the revision numbers, do not think of them as version numbers -- they are _not_ -- they represent the revision number of the repository, and do not relate to any specific file, project or module; and in this, SVN is different than CVS and other version control systems. Project version numbers are usually maintained by tagging: You create a new "Tag" and call it "ICS_v6.5" or whatever (and add a log note specifying the revision number from where it was created, for reference). This marks a specific milestone or point in time in the repository as belonging to that version. The revision numbers are for internal repository use and code maintenance and administration; and they identify merely a change to the repository, not even which files where changed (although this is available in the revision log). SVN does not make any distinction between files, directories, projects, etc -- all those things are for the developer's convenience. To SVN, the repository is one big file stream, so adding a directory or a project means nothing but a change to the repository (like a diff patch), which increments its revision number. This is a very subtle point, but it is very important when dealing with SVN. Therefore, it makes no difference if all projects exist in the same repository or not, as long as your file organization is coherent. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using SourceForge for ICS ?
Currently I don't plan to put ICS-SSL on SourceForge. I also wouldn't recommend it, until that time when you release it as open source (if ever you intend to do so). Still, it wouldn't hurt at all to set up SVN in your local machine to maintain the source :) -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Using SourceForge for ICS ?
> /icsv(n)
> |-branches
> | |-ics-ssl
> |-tags
> | |-ics-ssl
> | | |- beta(n)
> | |-ics
> | |- release(n)
> |-trunk
> |-ics
There's a few questions I have with your suggested
structure:
1. Is ICS-SSL really a branch of ICS, or should it be
considered a separate project? Branches, in my
opinion, should be temporary code paths destined to
eventually merge with the main trunk, such as to add
new features, fix bugs, etc.
2. Does ICS v6 represent a completely different
code-base than ICS v5, or is it a natural progression
for it? If the former, then they indeed should be
separte projects. But if the latter, they should
form part of the same code base: If ICS v5 is
currently the "stable" version, and ICS v6 represents
a new version that will eventually supplant it, then
I suggest ICS v5 represent the main trunk, and ICS v6
become a branch of it. Once ICS v6 matures and
replaces v5, it will be merged into the main trunk,
and v5 set as a Tag. But if v6 represents the
version where most development will be done, and v5
is only for legacy support, then it should be the
other way around.
Also, keep in mind that merging is done locally in
the user's working directory, not directly in the
repository. To merge, you select a source path from
the repository, and specify which revisions to
include; SVN will then merge those changes with your
working directory (representing the target repository
path). Once all conflicts are resolved, the updated
(merged) working directory can be commited by the user.
Therefore, it is possible for users to revert
accidentally changes commited previously, by
commiting "wrongly" merged files. The good thing is
that the changes were not lost (they are still in the
repository history), and can easily be returned.
By "wrongly merged files", I mean that the user
mistakenly overwrote other's changes with his own or
with an older version of code. This is the scenario
that I alluded to before, and it is fairly common
among people who are not used to version control systems.
-dZ.
>--- Original Message ---
>From: Arno Garrels[mailto:[EMAIL PROTECTED]
>Sent: 10/8/2007 1:03:09 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] Using SourceForge for ICS ?
>
>DZ-Jay wrote:
> On Oct 7, 2007, at 14:57, Arno Garrels wrote:
>
>> Isn't it safe to use the Copy-Modify-Merge
solution, described in the
>> online-help ?
>
> Yes, it is very safe.
Now that I checked how to merge particular changes
made in
branches to the main source tree under trunk I would like
to suggest the following, same structure for two
different
repositories one for V5 and one for V6:
/icsv(n)
|-branches
| |-ics-ssl
|-tags
| |-ics-ssl
| | |- beta(n)
| |-ics
| |- release(n)
|-trunk
|-ics
Where the ics-ssl branch and tags cannot be accessed by
common ics users. AFAIK it is only possible to merge
between common and SSL when the SSL code is in the same
repository, is that true? It works very well and makes it
very easy to maintain. If Francois does not want to
put the
SSL code into the project/repository as well ? I think we
won't safe very much. What do you think?
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
--
To unsubscribe or change your settings for TWSocket
mailing list
please goto
http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer stuck in destructor loop whenkilling threads
>> Change this. Its from top of my head so can be syntax errors. You have >> to move the destroy of the server also in the Execute mehod: Thank you, Wilfried; that worked like a charm. Now, since all exceptions are being swallowed by the TWSocket component, if I need to kill the entire app from, say, an event within the TWSocketThrdSrv (for example in OnBgException), should I post a message to the main thread, or is there a better way? -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] TWSocketThrdServer stuck in destructor loop when killing threads
Hello:
I'm having a problem with the TWSocketThrdServer.
My application has a worker thread that contains a
TWSocketThrdServer member to handle all incoming
requests. When the main thread finishes, it sends a
WM_QUIT message to the worker thread, which then
finishes and frees the TWSocketThrdServer. However,
if there are clients connected, the thrdserver stalls
in its destructor, while waiting for all its threads
to finish.
It only loops forever when there are clients
connected and the worker thread is terminated. But
if there are no clients connected, it works fine.
Can someone offer any help? Most likely I'm doing
something wrong. (Below is an example of my code.)
Also, I need to be able to terminate the entire
application if something goes wrong while processing
clients. What is the best way to do this? Should I
post a message to the main thread from a
TWSocketThrdServer event in the worker thread?
Thanks!
dZ.
My code is somewhat like this (this is very much
simplified):
Interface
Type
TServerThrd = Class(TThread)
Private
FSocketSrv: TWSocketThrdServer;
Public
Constructor Create; Reintroduce;
Destructor Destroy; Override;
Procedure Execute; Override;
End;
TQApp = Class(TObject)
Private
FServerThrd : TServerThrd;
Public
Constructor Create;
Destructor Destroy; Override;
End;
Implementation
{ TQApp }
Constructor TQApp.Create;
Begin
FServerThrd := TServerThrd.Create(False);
End;
Destructor TQApp.Destroy
Begin
Try
Try
PostThreadMessage(FServerThrd.ThreadID,WM_QUIT,0,0);
Finally
FServerThrd.WaitFor;
FServerThrd.Free;
End;
Finally
Inherited Destroy;
End;
End;
{ TServerThrd }
Constructor TServerThrd.Create;
Begin
Inherited Create(True);
End;
Destructor TServerThrd.Destroy;
Begin
Try
If Assigned(FSocketSrv) Then Begin
FSocketSrv.Free; // <<-- HERE! (waits forever)
End;
Finally
Inherited Destroy;
End;
End;
Procedure TServerThrd.Execute;
Begin
Try
FSocketSrv := TWSocketThrdServer.Create(Nil);
FSocketSrv.Listen();
FSocketSrv.MessageLoop;
Finally
// do other cleanup
End;
End;
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Using SourceForge for ICS ?
> Yes, and TortoiseSVn looks like a very cool > and powerfull tool on the first glance! It is. I don't need nor care about BDS integration anymore; I do all manipulations of the source files through the Explorer shell using TortoiseSVN. It even overlays the folder/file icons with symbols of their status (modified, conflict, updated, etc.). -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer - BogusOnDataAvailabletriggeredwhen Closed.
> > I think the problem is that in
TCustomWSocket.InternalClose the message
> > pump is called
>
> I think you right about that. As I recall
CloseDelayed was introduced if
> it was needed to Close from in one of the events.
Most likely that was
> the reason.
So should I call CloseDelayed() or Shutdown(1) from
the event? I want to make sure that the client
receives the data last sent from the server right
before closing. For example:
// OnDataAvailable event handler
Begin
If (NeedToShutdownConnection) Then Begin
Client.SendLine('-ERR Closing connection.');
Client.Shutdown(1); // Or CloseDelayed() ...?
End;
End;
Thanks again to all of you,
-dZ.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer - Bogus OnDataAvailabletriggeredwhen Closed.
> > Close() ultimately calls Shutdown(1) -- so wouldn't it have the same > > effect? > > As I recall not exacly the same. Close calls Shutdown(1) and close the > socket. If you call Shutdown(1) the socket will not be immediatly close, > but if there is still some data it will be send, and the other end will > tell it is ready to close when receiving the data. Then the socket will > be closed by winsock (and OnSessionClosed is then called). Aha! Ok, I understand now. I'll look deeper in the TWSocket code to understand it better, but I get the picture. > > I thought the buffer > > was cleared when read (ReceivedStr property), or am I wrong? > > Yes it is. If OnDataAvailable is called when you call close (with some > data) then the other end has send some data, or there is somewhere a > re-entrance problem (somewhere calling the message pump?). And this perhaps is the problem, because it seems to be re-entering without receiving new data. I'll check my code to see if I'm stupidly calling the message pump somewhere else (I probably am). Thanks! -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] TWSocketThrdServer - Bogus OnDataAvailable triggered when Closed.
Hello:
I'm using TWSocketThrdServer and processing
client data from within the OnDataAvailable event
handler (client is set to LineMode=True). I've
noticed that if the data transaction is completed and
I call Client.Close from within this event, the event
is called again with the previous ReceivedStr.
Here's a sample of the code I am using:
Procedure TMyServer.HandleDataAvailable(Sender:
TObject; Error: Word);
Var
DataStr: String;
bDone: Boolean;
Begin
If (Error = 0) Then Begin
With (Sender As TMyClient) Do Begin
DataStr := ReceiveStr;
// parse the DataStr and do
// whatever needs to be done.
// bDone may be set here.
If (bDone) Then Begin
SendLine('Sayonara.');
TMyClient(Sender).Close; // <<-- HERE!
End;
End;
End Else Begin
// Handle errors...
TMyClient(Sender).Abort;
End;
End;
When that Close method is called, the event is
immediately re-entered with the same data. Am I
doing something stupid?
Thanks,
-dZ.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] Using SourceForge for ICS ?
Hello: I've used SourceForge before, and it is a nice environment for distribution and project sharing and participation. I will suggest you use SubVersion (SVN) -- it is a considerably better than CVS. As a matter of fact, it was designed to overcome some of the limitations of CVS. SVN and CVS have different ways of working, so if you are used to using CVS, you'll have to unlearn some concepts and learn some new ones. It may seem confusing at first, but once you understand SubVersion's concepts, everything seems so natural. (even more so than with CVS, which is clunky). Plus, if you use the TortoiseSVN client, it integrates very nicely with the Windows Explorer (and I believe there's a BDS plug-in), so you'll never have to face the dreaded WinCVS GUI ever again. I've worked with SVN for the past few years, so I am willing to offer any assistance you may need. -dZ. >--- Original Message --- >From: Francois PIETTE[mailto:[EMAIL PROTECTED] >Sent: 10/2/2007 12:55:22 PM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] Using SourceForge for ICS ? > >Hello Guys ! I'm considering the option of pushing ICS to SourceForge and I would like to have your opinion. Does someone already have a real experience of SourceForge as a developper ? The first decision is should I select CVS or SVN ? Any advice appreciated. -- [EMAIL PROTECTED] 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://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Cancelling TWSocketServer client connection
Francois, Thanks for your response. I understand what you are saying, and will change my code accordingly. However, it occurs to me that a lot of processing seems to be occurring from the moment the client arrived until the connection is established and the OnClientConnect event is fired; and if the client needs to be dropped for some reason, all this processing is wasted. Would it then be a good idea to offer a cancelling mechanism from the first event that would skip all the rest? I could work on something if you think its worth it. -dZ. >--- Original Message --- >From: Francois PIETTE[mailto:[EMAIL PROTECTED] >Sent: 10/1/2007 12:35:46 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Cancelling TWSocketServer client connection > >At the time OnClientCreate is called, the socket is not assigned yet to the connection. So it is not easy to cancel the connection. OnClientConnect is a better place. From there you can call Shutdown to terminate the connection you don't want. Have a look at the source code for TCustomWSocketServer.TriggerSessionAvailable. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Another BCB2007 compatibility problem (of demos)
RAD Studio 2007 brings ICS? Is it in the additional components, or as part of the default distribution? -dZ. >--- Original Message --- >From: Francois PIETTE[mailto:[EMAIL PROTECTED] >Sent: 10/1/2007 12:19:57 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Another BCB2007 compatibility problem (of demos) > >Have you used ICS version which included in RAD Studio 2007 ? -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Cancelling TWSocketServer client connection
Hello: I am performing a series of steps when a new client connection is received (in the OnClientCreate event handler) which may cause the connection to become invalid (or unwelcomed, for various reasons). What would be the best way to drop the client session at this point? Calling Client.Close does not seem to do anything, since the real connection doesn't seem to be ready until the OnClientConnect event is triggered. After TriggerClientConnect() is called (the next step in the chain), the state of the client is checked, and whether the handler destroyed it, but nothing is checked after TriggerClientCreate() is called. I was wondering if this is an oversight or if this is by design -- in which case, I should perform my checks on that event handler (?). Seems to me that if the server decides to not accept the connection, I should be able to drop it as soon as possible. Can anybody offer any suggestions? Thanks, -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer graceful shutdown
>--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] > > Isn't this list great? Where else do you get faster support for > free software? Yes, it is. Thank you both for your quick responses. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] TWSocketThrdServer graceful shutdown
Thanks Wilfried. Close() will do it. What then does Shutdown(x) do? I see that Close() calls it with an argument of 1 (SD_SEND), which according to a comment is for "graceful close". Does it stop sending data? -dZ. >--- Original Message --- >From: Wilfried Mestdagh[mailto:[EMAIL PROTECTED] >Sent: 9/28/2007 12:03:57 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] TWSocketThrdServer graceful shutdown > >Hello dz, Just call Close method. server will stop listening. Note that calling Close will not stop current connections, it only stops listening. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Friday, September 28, 2007, 17:44, [EMAIL PROTECTED] wrote: > Hello: > I using TWSocketThrdServer in a server > application and was wondering if there is a > recommended method to call for a graceful shutdown -- > one that will stop listening when all current > connections are completed. > Thanks, > -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] TWSocketThrdServer graceful shutdown
Hello: I using TWSocketThrdServer in a server application and was wondering if there is a recommended method to call for a graceful shutdown -- one that will stop listening when all current connections are completed. Thanks, -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] TWSocket multi-client example
Hello: I need to write a TService application that will receive (potentially) multiple client TCP connections concurrently, and perform some simple stateful transactions with them. For example: 1. Client-A connects to the server 2. Server responds with banner 3. Client-A sends data 4. Client-A sends end-of-data marker 5. Server responds with ERR or OK code 6. Server responds with receipt ID 7. Client-A closes connection As you can see, its sort of like an SMPT server, but much, much simpler. Does TWSocket support multiple concurrent connections? If not, do I need to implement this by spawning a new thread for each client, or is there a more efficient way? Is there an example of such application? From what I found in the ICS demo applications, some use multiple forms for each client. Any guidance or samples will be very much appreciated. Thank you, -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] httpcli v6 "bad request"
Francois, Then there are situations that your previous argument will fail: Consider an application using HttpCli that does not automatically encode URLs in the URL property. Users will complain that "If I enter in IE it works, but your software is broken!". If your response is "have the developer fix his application", then it is the same as saying "have the server developer fix his relocation code", no? My point is that if you want your component to behave in the same expected ways as a browser would, then the appropriate solution is to force automatic encoding all the time, which is what browsers do. If already encoded URLs are taken into consideration, then it won't break any existing code. If you think -- like me -- that it is the responsibility of the application developer to properly encode URLs, and not the component, then the solution for those applications that require the IE-like behaviour is for the developer to call UrlEncode himself at the application level, and to not use FollowRedirect, but to handle redirections himself and properly encode URLs. One more thing: Your concern about breaking existing code when encoding the URL property holds true also if you UrlEncode the redirecion URL. That is, if the server responds with a properly encoded URL, and you re-encode it again, you will mangle the URL. And if you can take special care to compensate for this, why can't it be done for all URLs? I'm sorry for dragging this on, but I just don't understand the push for solving "the redirection" issue as a special case. If you think we've gone off-topic, feel free to reply by personal e-mail. Thanks -dZ. >--- Original Message --- >From: Francois PIETTE[mailto:[EMAIL PROTECTED] >Sent: 4/20/2007 1:17:40 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] httpcli v6 "bad request" > >> I do not agree that this is a relocation-specific > issue, and if we want the component to mimic the > expected behaviour of standard browsers, it needs to > automatically encode all URLs when composing the > request, at the latest point when the location > address has been "commited" immutably. I don't think the component has to encode all URL, specialy surely not encode the URL provided in the URL property. This would break a lot of existing code. BUT, in the relocation process, it is OK to encode any URL involved because the user has no effective acces to this URL. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] httpcli v6 "bad request"
That's for general URI (Uniform Resource Identifier). I believe RFC #1738 covers URL (Uniform Resource Locator) specifically. It narrows down considerably the scope of escaping as only a few valid combinations, characters, and formats are valid for WWW addresses. -dZ. >--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] >Sent: 4/20/2007 10:41:53 AM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] httpcli v6 "bad request" > >[EMAIL PROTECTED] wrote: >> --- Original Message --- >>> From: Francois > PIETTE[ mailto:[EMAIL PROTECTED] >> Sent: 4/19/2007 2:46:48 PM >> To : twsocket@elists.org >> Cc : >> Subject : RE: Re: [twsocket] httpcli v6 "bad request" >> > >>> Agreed, so we need a FAST routine. URLEncode > currently >>> isn't smart enough to encode a complete URL, and it is >>> slow (result := result + ..) >> >> Next question is how smart should such a routine act? >> Should it check for a valid URL in general or shall it >> just check for valid encoding? >> Should it auto-complete incomplete as well as > auto-correct >> invalid URLs like IE? When you start thinking about > this stuff >> the routine in mind becomes slower and slower :( > >> Making URLEncode faster is probably enough for >> the component. Checking valid >> URL and autocomplete is another thing. > > I don't know if this is what Arno had in mind with > the validation, but as I mentioned before, there is > one more catch: what if the application encoded the > URL to begin with? > Then all percent symbols will be > re-encoded and the URL mangled. For this reason you > either need to unencode-reencode (slow!), or check > for encoding and only encode if necessary. RFC2396 sounds rather complicated: " 2.4.2. When to Escape and Unescape A URI is always in an "escaped" form, since escaping or unescaping a completed URI might change its semantics. Normally, the only time escape encodings can safely be made is when the URI is being created from its component parts; each component may have its own set of characters that are reserved, so only the mechanism responsible for generating or interpreting that component can determine whether or not escaping a character will change its semantics. Likewise, a URI must be separated into its components before the escaped characters within those components can be safely decoded. " ( http://www.faqs.org/rfcs/rfc2396.html ) We probably have to bind encoding to function ParseUrl() somehow. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html > -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] httpcli v6 "bad request"
> The main issue is however that with the followrelocate
> set it will generate an error while a browser will not.
As has been stated before, that is not the main
issue. The main issue is that the HttpCli component
does not perform *any* encoding of URLs prior to
sending a request to the server, which runs contrary
to the behaviour of any standard browser. It just so
happens that the problem manifested itself in your
case as a relocation address with as space on it.
I do not agree that this is a relocation-specific
issue, and if we want the component to mimic the
expected behaviour of standard browsers, it needs to
automatically encode all URLs when composing the
request, at the latest point when the location
address has been "commited" immutably.
This means that it has to compensate for pre-encoded
URLs (just like standard browsers do: give IE an
encoded URL and it will leave it alone, give it one
with funky characters and it will encoded it).
-dZ.
>--- Original Message ---
>From: Frans van Daalen[mailto:[EMAIL PROTECTED]
>Sent: 4/19/2007 3:58:57 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] httpcli v6 "bad request"
>
>my 2 cents on this :
If you feed Thttpcli.url with a invalid url no
urldecode is executed. To
keep consistency in behavior I would not just do an
automatic urldecode on a
relocate.
The main issue is however that with the
followrelocate set it will generate
an error while a browser will not.
To allow a programmer to make a decision on an
invalid relocate url the
component must provide an option to do so.
I therefore see 3 possible solutions.
1) A new property AutoDecodeRelocationUrl type
Boolean. Default FALSE. If
set TRUE will execute a urldecode on the relocate AND
possible on the
httpcli.url also. But if it include the later option
as well the name maybe
should be AutoUrlDecode.
2) A new event OnRelocationRecieved(data : String;
Accept : Boolean) to be
called around line 2675 (procedure getheaderlinenext)
--
{
co=32&js=1.4&sr=1024x768&re=
http://www.thesite.com/you.html }
FLocationFlag := TRUE;
if Proxy <> '' then begin
--
something like
--
{
co=32&js=1.4&sr=1024x768&re=
http://www.thesite.com/you.html }
baccept := true;
if Assigned(FOnRelocationRecieved) then
FOnRelocationRecieved(data,baccept);
If baccept then
FLocationFlag := TRUE;
if Proxy <> '' then begin
--
This would allow the programmer to temporary overrule
the FFollowRelocation
setting on demand but also allow adjustment of the
received header data. I
think that would enhance flexibility.
3) A change to the procedure getheaderlinenext to
just change the received
data. In my opion not the best option as it can cause
confusion about what
is really received.
Feedback appreciated :>>
--
To unsubscribe or change your settings for TWSocket
mailing list
please goto
http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] httpcli v6 "bad request"
>--- Original Message --- >From: Francois PIETTE[mailto:[EMAIL PROTECTED] >Sent: 4/19/2007 2:46:48 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] httpcli v6 "bad request" > >>> Agreed, so we need a FAST routine. URLEncode currently >> isn't smart enough to encode a complete URL, and it is >> slow (result := result + ..) > > Next question is how smart should such a routine act? > Should it check for a valid URL in general or shall it > just check for valid encoding? > Should it auto-complete incomplete as well as auto-correct > invalid URLs like IE? When you start thinking about this stuff > the routine in mind becomes slower and slower :( > Making URLEncode faster is probably enough for > the component. Checking valid > URL and autocomplete is another thing. I don't know if this is what Arno had in mind with the validation, but as I mentioned before, there is one more catch: what if the application encoded the URL to begin with? Then all percent symbols will be re-encoded and the URL mangled. For this reason you either need to unencode-reencode (slow!), or check for encoding and only encode if necessary. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] httpcli v6 "bad request"
Frans, As I mentioned before, replacing spaces will still leave you open to other invalid characters. If you want a quick fix for your current problem, then I suggest URL-encoding the entire URL instead of just the the spaces. Its been a while since I've used HttpCli, so I'm not sure if it provides one, but creating a URL encoding function is not that hard (its basically turning every invalid character into a code of the form %XX where XX represents the ASCII code for character in Hex), contact me privately if you need help with it. As a long term solution, if Francois really wants to replicate browsers' behavior, then the URL must be URL-encoded at the latest moment when the request is being constructed to cover all possible capture points. Notice that this will involve a 2 step process: URL-decode and then URL-encode, to compensate for strings that have already been encoded by the application externally. -dZ. >--- Original Message --- >From: Frans van Daalen[mailto:[EMAIL PROTECTED] >Sent: 4/19/2007 6:54:57 AM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] httpcli v6 "bad request" > >> > In my Ethereal dump the location-header of the 301-response already has > the space, so the server simply tries to redirect to an invalid URL, do > we really have to workaround such invalid URLs in the THttpCli? > With followRelocation := True this URL will generate a 400 on ThttpCli with absolutly no option to solve it except with a more or less illegal httpClient.FPath := stringreplace(httpclient.fpath,' ','%20',[rfreplaceall]); IE, Opera and possible other browser however will not generate a 400. I have no control over servers that generate a more or less invalid URL and it its hard to explain to any user why such a url is oke with IE etc and not with any ICS based product. As a reminder a quote from Francois in another posting " I remember long time ago we discussed this topic (post changed to get after relocation) and we concluded that it must be done so because most browser do not follow the standard and not doing like the browser will result in failure. That is probably how a bug in a well known browser become a de-facto standard ! Like it or not, if you don't do the same, your program will be accused of malfunction even if it perfectly follow the standard. " And to add to this: I needed more then a few days before finally finding this one, it's onyl one single space that caused this :-) -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] httpcli v6 "bad request"
>--- Original Message --- >From: Arno Garrels[mailto:[EMAIL PROTECTED] >Sent: 4/19/2007 6:37:09 AM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] httpcli v6 "bad request" > No idea, I can only see that the send header in this case will have > the %20 included already. > In my Ethereal dump the location-header of the 301-response already has > the space, so the server simply tries to redirect to an invalid URL, do > we really have to workaround such invalid URLs in the THttpCli? That is my point: that it is not a transport protocol issue, but a client application issue. URLs should be either URL-encoded by automatically prior to _any_ request by the component; independently by the application; or ignored as invalid. But I do not think there should be a special case for invalid URLs in redirect responses, with spaces. -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] TWSocket and TWSocketServer TCP Header (full packet)
hi to all community, I'm in trouble about a problem: is it possible to get FULL TCP PACKET (Header + Data)?? In "OnDataAvaiable" event I've got just the Data but nothing about Sequence_Number, Flags, IDs etc..etc.. Thx in advance -Antony- -- Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom http://click.libero.it/infostrada -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] SMTP connection limit
Hello: Most ISP's SMTP servers limit the amount of concurrent connections from the same source to about 10 or 20. This is intended to prevent automatic spamming and mail bombing runs, or to at least hinder or limit their impact. This is pretty much an industry standard nowadays (along with rejecting connections from dynamic IP addresses). Making the limit configurable is a good idea, and I would suggest a default limit of no more than 20. Like Arno said in his post, asynchroneous connections to the same server do not necessarily increase performance significantly so it shouldn't matter that much to the user. -dZ. >--- Original Message --- >From: Veit Zimmermann[mailto:[EMAIL PROTECTED] >Sent: 3/8/2007 6:42:03 AM >To : twsocket@elists.org >Cc : >Subject : RE: [twsocket] SMTP connection limit > >Hi Are there providers which limit the number of concurrent SMTP connections? In other words: Do I have to make the maximum number of connections for asynchronous operation flexible and what would be a good practice approach (besides making it user configurable). TIA -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] FTPClient specifying a port other than 21...
Thanks for the previous posts. I guess the bottom line is, does FTPClient work with other ports besides port 21 for the version last revised: Apr 18, 2003. I am currently using Delphi 3? I have tried specifying other ports but receive the message 10060 on a file transmit as previously reported. Thanks in advance, James -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
