Re: [twsocket] Bug in SmtpProt.pas
Outlook *does* indeed break long subject lines. Here's an example of a message I just sent using Outlook 2000: It does not when I test (Outlook 2003 SP1, but also with Norton Antivirus, dont know if this affects this). Other lines are split but not the subject. Anyway, TCustomSmtpClient.DataNext would fail even when using continuation lines every 74 char if the total length is longer than 1024. Again, this is a limit imposed by the protocol itself, so the application should guard against it. That said, I agree that the component could avoid potential buffer overflows if it included the check, just as long as it does not impact performance and functionality adversely. Anyway, the RFC 821 says that the maximum line length including CRLF is 1000 chars. If I use a subject that is longer, and break the line at 74 with CRLF and tab, the header-subject would be RFC-compliant, but the smtp-component would crash. Regards Bjørnar -- 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] Bug in SmtpProt.pas
Anyway, the RFC 821 says that the maximum line length including CRLF is 1000 chars. If I use a subject that is longer, and break the line at 74 with CRLF and tab, the header-subject would be RFC-compliant, but the smtp-component would crash. I guess I could use OnProcessHeader and split the lines into more lines if to long. But I think StrPCopy should be changed to StrPLCopy, I think this would not decrease performance, just stop the component from crashing if a line is to long. Regards Bjørnar -- 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] Speed and buffered file stream
Hello, I've uploaded a tiny buffered file stream class as well as a simple test program. It is amazing fast when small chunks are read/written. Seeking is slower than TFileStream :( http://www.duodata.de/misc/bufstrm.zip Compiled it with D5 and D7, supports 64 bit from D6 upwards. I've been using the class with TSmtpCli (reading), and great success over one year now, write mode, seeking, and 64 bit support was added, these new features are not yet tested in an application, so your feedback is welcome. Arno Garrels -- 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] Bug in SmtpProt.pas
Bjørnar Nielsen wrote: Anyway, the RFC 821 says that the maximum line length including CRLF is 1000 chars. If I use a subject that is longer, and break the line at 74 with CRLF and tab, the header-subject would be RFC-compliant, but the smtp-component would crash. I guess I could use OnProcessHeader and split the lines into more lines if to long. But I think StrPCopy should be changed to StrPLCopy, I think this would not decrease performance, just stop the component from crashing if a line is to long. Yes, it should be fixed, anyway it won't prevent the developer from checking for correct line length, so it is not so important. Arno Garrels -- 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] Bug in SmtpProt.pas
On Oct 26, 2005, at 04:18, Bjørnar Nielsen wrote: Outlook *does* indeed break long subject lines. Here's an example of a message I just sent using Outlook 2000: It does not when I test (Outlook 2003 SP1, but also with Norton Antivirus, dont know if this affects this). Other lines are split but not the subject. So the subject arrives as one continuous line of 1000+ characters? And the SMPT server permits this? Strange. I'll take your word for it, as I have no access to Outlook 2003 to test. dZ. -- God is real, except when declared as integer; and infinite when divided by zero. -- 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] Bug in SmtpProt.pas
DZ-Jay wrote: On Oct 26, 2005, at 04:18, Bjørnar Nielsen wrote: Outlook *does* indeed break long subject lines. Here's an example of a message I just sent using Outlook 2000: It does not when I test (Outlook 2003 SP1, but also with Norton Antivirus, dont know if this affects this). Other lines are split but not the subject. So the subject arrives as one continuous line of 1000+ characters? And the SMPT server permits this? Strange. I'll take your word for it, as I have no access to Outlook 2003 to test. Some mail servers reformat invalid headers and mime messages, with sometimes very strange results. Also some MTA's would drop the connection on receiving very long lines since they assume a buffer overrun attack. One note on OE 6, it truncates the subject line at 266 chars silently. Arno Garrels -- 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] Speed and buffered file stream
I've uploaded a tiny buffered file stream class as well as a simple test program. It is amazing fast when small chunks are read/written. Seeking is slower than TFileStream :( I'll try in one of my applications, but it won't be until next week. For the FTP server, I often have multiple PCs downloading the same files, in some cases 30 or 40 megs. With the normal TFileStream, presumably Windows will be effectively buffering the file once, and each separate stream will be reading from common windows buffers, in the normal read chunks specified by the server. I've never really understood whether this was efficient, or just simple. So what are the implications of buffering the same file multiple times? Presumably just the extra memory for the buffer? I have a couple of special files that are read thousands of times of day, both less than 1 meg that I could keep in a memory stream for efficiency. Angus -- 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] Bug in SmtpProt.pas
On Oct 26, 2005, at 06:06, Arno Garrels wrote: So the subject arrives as one continuous line of 1000+ characters? And the SMPT server permits this? Strange. I'll take your word for it, as I have no access to Outlook 2003 to test. Some mail servers reformat invalid headers and mime messages, with sometimes very strange results. Also some MTA's would drop the connection on receiving very long lines since they assume a buffer overrun attack. That's what I was alluding at; I was assuming he meant that the message would arrive intact with the entire subject line without breaks or truncation. One note on OE 6, it truncates the subject line at 266 chars silently. Outlook 2000 does the same thing, and it won't let you enter a subject line longer than 256 characters (but it split it with CRLF+TAB after every 74 chars.) dZ. -- DZ-Jay [TeamICS] -- 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] Bug in SmtpProt.pas
That's what I was alluding at; I was assuming he meant that the message would arrive intact with the entire subject line without breaks or truncation. It does, but I can't write more than 256 chars in the subject-line. The subject is kept as a single line, no splits. The subject is sent this way and I receive it back from the mailserver the same way. Regards Bjørnar -- 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] Speed and buffered file stream
Angus Robertson - Magenta Systems Ltd wrote: I've uploaded a tiny buffered file stream class as well as a simple test program. It is amazing fast when small chunks are read/written. Seeking is slower than TFileStream :( I'll try in one of my applications, but it won't be until next week. For the FTP server, I often have multiple PCs downloading the same files, in some cases 30 or 40 megs. With the normal TFileStream, presumably Windows will be effectively buffering the file once, and each separate stream will be reading from common windows buffers, in the normal read chunks specified by the server. I've never really understood whether this was efficient, or just simple. So what are the implications of buffering the same file multiple times? Presumably just the extra memory for the buffer? You save a lot of API calls. It depends on the ratio of block size and buffer size. The SmtpCli reads files byte by byte hence it benefits from a buffered stream enormously. I have a couple of special files that are read thousands of times of day, both less than 1 meg that I could keep in a memory stream for efficiency. I think that's the fasted way of caching. Angus -- 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] Bug in SmtpProt.pas
Bjørnar Nielsen wrote: That's what I was alluding at; I was assuming he meant that the message would arrive intact with the entire subject line without breaks or truncation. It does, but I can't write more than 256 chars in the subject-line. The subject is kept as a single line, no splits. The subject is sent this way and I receive it back from the mailserver the same way. That's an old bug in OE, you should not copy M$ bugs but wrap the subject line. BTW: I think having ~1000 chars for the subject line is far enough, or do you know a client that would display such long subjects properly? Arno Garrels -- 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] Bug in SmtpProt.pas
That's an old bug in OE, you should not copy M$ bugs but wrap the subject line. BTW: I think having ~1000 chars for the subject line is far enough, or do you know a client that would display such long subjects properly? I just testet Outlook, and it seems difficult to show the mail correct if the subject is very long and the lines are split. In my test it seems the best is to not to split the line and keep the subject not to long. Regards Bjørnar -- 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] C++ Builder - bcbie60 problem
Hi. I've seen this question asked before, but didn't see a solution posted in the archives. I've just compiled the latest beta of ICS, and when I attempt to install the packages, I get a warning that BCB can not install the package because bcbie60 already contains the unit shdocvw_ocx. Has anyone seen this before? Any ideas at resolving it? Thanks, Ian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, October 26, 2005 8:00 AM To: twsocket@elists.org Subject: TWSocket Digest, Vol 140, Issue 4 Send TWSocket mailing list submissions to twsocket@elists.org To subscribe or unsubscribe via the World Wide Web, visit http://www.elists.org/mailman/listinfo/twsocket or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of TWSocket digest... Today's Topics: 1. Re: Bug in SmtpProt.pas (DZ-Jay) 2. Re: Bug in SmtpProt.pas (Bj?rnar Nielsen) 3. Re: Speed and buffered file stream (Arno Garrels) 4. Re: Bug in SmtpProt.pas (Arno Garrels) -- Message: 1 Date: Wed, 26 Oct 2005 06:35:02 -0400 From: DZ-Jay [EMAIL PROTECTED] Subject: Re: [twsocket] Bug in SmtpProt.pas To: ICS support mailing twsocket@elists.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed On Oct 26, 2005, at 06:06, Arno Garrels wrote: So the subject arrives as one continuous line of 1000+ characters? And the SMPT server permits this? Strange. I'll take your word for it, as I have no access to Outlook 2003 to test. Some mail servers reformat invalid headers and mime messages, with sometimes very strange results. Also some MTA's would drop the connection on receiving very long lines since they assume a buffer overrun attack. That's what I was alluding at; I was assuming he meant that the message would arrive intact with the entire subject line without breaks or truncation. One note on OE 6, it truncates the subject line at 266 chars silently. Outlook 2000 does the same thing, and it won't let you enter a subject line longer than 256 characters (but it split it with CRLF+TAB after every 74 chars.) dZ. -- DZ-Jay [TeamICS] -- Message: 2 Date: Wed, 26 Oct 2005 12:52:03 +0200 From: Bj?rnar Nielsen [EMAIL PROTECTED] Subject: Re: [twsocket] Bug in SmtpProt.pas To: 'ICS support mailing' twsocket@elists.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 That's what I was alluding at; I was assuming he meant that the message would arrive intact with the entire subject line without breaks or truncation. It does, but I can't write more than 256 chars in the subject-line. The subject is kept as a single line, no splits. The subject is sent this way and I receive it back from the mailserver the same way. Regards Bj?rnar -- Message: 3 Date: Wed, 26 Oct 2005 13:03:07 +0200 From: Arno Garrels [EMAIL PROTECTED] Subject: Re: [twsocket] Speed and buffered file stream To: ICS support mailing twsocket@elists.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Angus Robertson - Magenta Systems Ltd wrote: I've uploaded a tiny buffered file stream class as well as a simple test program. It is amazing fast when small chunks are read/written. Seeking is slower than TFileStream :( I'll try in one of my applications, but it won't be until next week. For the FTP server, I often have multiple PCs downloading the same files, in some cases 30 or 40 megs. With the normal TFileStream, presumably Windows will be effectively buffering the file once, and each separate stream will be reading from common windows buffers, in the normal read chunks specified by the server. I've never really understood whether this was efficient, or just simple. So what are the implications of buffering the same file multiple times? Presumably just the extra memory for the buffer? You save a lot of API calls. It depends on the ratio of block size and buffer size. The SmtpCli reads files byte by byte hence it benefits from a buffered stream enormously. I have a couple of special files that are read thousands of times of day, both less than 1 meg that I could keep in a memory stream for efficiency. I think that's the fasted way of caching. Angus -- Message: 4 Date: Wed, 26 Oct 2005 13:26:12 +0200 From: Arno Garrels [EMAIL PROTECTED] Subject: Re: [twsocket] Bug in SmtpProt.pas To: ICS support mailing twsocket@elists.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Bj?rnar Nielsen wrote: That's what I was alluding at; I was assuming he meant
Re: [twsocket] Bug in SmtpProt.pas
Bjørnar Nielsen wrote: That's an old bug in OE, you should not copy M$ bugs but wrap the subject line. BTW: I think having ~1000 chars for the subject line is far enough, or do you know a client that would display such long subjects properly? I just testet Outlook, and it seems difficult to show the mail correct if the subject is very long and the lines are split. In my test it seems the best is to not to split the line and keep the subject not to long. As far as I know, it splits it for transport only, but concatenates all CRLF+TAB delimited lines as one single header. 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] C++ Builder - bcbie60 problem
Hello Ian, Yes I have faced this problem before. Not exactly remembering how did I passed it but creating a fresh package would help (IMO). Best Regards, SubZ - Original Message - From: Ian Tuck [EMAIL PROTECTED] To: twsocket@elists.org Sent: Wednesday, October 26, 2005 6:16 PM Subject: [twsocket] C++ Builder - bcbie60 problem Hi. I've seen this question asked before, but didn't see a solution posted in the archives. I've just compiled the latest beta of ICS, and when I attempt to install the packages, I get a warning that BCB can not install the package because bcbie60 already contains the unit shdocvw_ocx. Has anyone seen this before? Any ideas at resolving it? Thanks, Ian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, October 26, 2005 8:00 AM To: twsocket@elists.org Subject: TWSocket Digest, Vol 140, Issue 4 Send TWSocket mailing list submissions to twsocket@elists.org To subscribe or unsubscribe via the World Wide Web, visit http://www.elists.org/mailman/listinfo/twsocket or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of TWSocket digest... Today's Topics: 1. Re: Bug in SmtpProt.pas (DZ-Jay) 2. Re: Bug in SmtpProt.pas (Bj?rnar Nielsen) 3. Re: Speed and buffered file stream (Arno Garrels) 4. Re: Bug in SmtpProt.pas (Arno Garrels) -- Message: 1 Date: Wed, 26 Oct 2005 06:35:02 -0400 From: DZ-Jay [EMAIL PROTECTED] Subject: Re: [twsocket] Bug in SmtpProt.pas To: ICS support mailing twsocket@elists.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed On Oct 26, 2005, at 06:06, Arno Garrels wrote: So the subject arrives as one continuous line of 1000+ characters? And the SMPT server permits this? Strange. I'll take your word for it, as I have no access to Outlook 2003 to test. Some mail servers reformat invalid headers and mime messages, with sometimes very strange results. Also some MTA's would drop the connection on receiving very long lines since they assume a buffer overrun attack. That's what I was alluding at; I was assuming he meant that the message would arrive intact with the entire subject line without breaks or truncation. One note on OE 6, it truncates the subject line at 266 chars silently. Outlook 2000 does the same thing, and it won't let you enter a subject line longer than 256 characters (but it split it with CRLF+TAB after every 74 chars.) dZ. -- DZ-Jay [TeamICS] -- Message: 2 Date: Wed, 26 Oct 2005 12:52:03 +0200 From: Bj?rnar Nielsen [EMAIL PROTECTED] Subject: Re: [twsocket] Bug in SmtpProt.pas To: 'ICS support mailing' twsocket@elists.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 That's what I was alluding at; I was assuming he meant that the message would arrive intact with the entire subject line without breaks or truncation. It does, but I can't write more than 256 chars in the subject-line. The subject is kept as a single line, no splits. The subject is sent this way and I receive it back from the mailserver the same way. Regards Bj?rnar -- Message: 3 Date: Wed, 26 Oct 2005 13:03:07 +0200 From: Arno Garrels [EMAIL PROTECTED] Subject: Re: [twsocket] Speed and buffered file stream To: ICS support mailing twsocket@elists.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Angus Robertson - Magenta Systems Ltd wrote: I've uploaded a tiny buffered file stream class as well as a simple test program. It is amazing fast when small chunks are read/written. Seeking is slower than TFileStream :( I'll try in one of my applications, but it won't be until next week. For the FTP server, I often have multiple PCs downloading the same files, in some cases 30 or 40 megs. With the normal TFileStream, presumably Windows will be effectively buffering the file once, and each separate stream will be reading from common windows buffers, in the normal read chunks specified by the server. I've never really understood whether this was efficient, or just simple. So what are the implications of buffering the same file multiple times? Presumably just the extra memory for the buffer? You save a lot of API calls. It depends on the ratio of block size and buffer size. The SmtpCli reads files byte by byte hence it benefits from a buffered stream enormously. I have a couple of special files that are read thousands of times of day, both less than 1 meg that I could keep in a memory stream for efficiency. I think that's the fasted way of caching. Angus
[twsocket] Sending a mix of text and records through TWSocket
Hi all, I'm trying to implement the client server architecture described here: http://tinyurl.com/benop My first approach was with Indy 10, but after some attempts, I found quite difficult to manage the complexity of multithread programming, so I dropped Indy and now I'm trying ICS. I had a positive experience with ICS HTTP and mail components some years ago and I feel more comfortable with event handling than multithreading... I found a very useful example here http://tinyurl.com/cqkmh , Server1.zip : thank you Wilfried :) I studied also the ICS FAQ about receiving high speed data http://tinyurl.com/762c6 Starting from various TCP client inlcuded in ICS examples, I tried to send through TWSocket a mix of text commands and records but I wasn't successful. Assuming a given record and his pointer... PTMyRec = ^TMyRec; TMyRec = packed record .. .. end; ... and following the protocol implemented in the above mentioned example (server1.zip) I'm trying to send a text command followed by a record. I tried this way from a generic client: var pr : PTMyRec; r : TMyRec; begin wsocket.LineMode := True; WSocket.SendStr(EditCommand.Text + #13#10); // the command is 'DATA ' // r fields filled with some data pr := @r; wsocket.LineMode := False; wsocket.Send(pr, SizeOf(r)); end; On the server, I receive correctly the text command but not the record. What I'm doing wrong? Thank you in advance for your replies. -- Geppy Piloni -- 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] Sending a mix of text and records through TWSocket
Geppy, It would be helpful to see how you are receiving it. Show us some code on the receive side of this. Kirk On 10/26/05, Geppy Piloni [EMAIL PROTECTED] wrote: Hi all, I'm trying to implement the client server architecture described here: http://tinyurl.com/benop My first approach was with Indy 10, but after some attempts, I found quite difficult to manage the complexity of multithread programming, so I dropped Indy and now I'm trying ICS. I had a positive experience with ICS HTTP and mail components some years ago and I feel more comfortable with event handling than multithreading... I found a very useful example here http://tinyurl.com/cqkmh , Server1.zip: thank you Wilfried :) I studied also the ICS FAQ about receiving high speed data http://tinyurl.com/762c6 Starting from various TCP client inlcuded in ICS examples, I tried to send through TWSocket a mix of text commands and records but I wasn't successful. Assuming a given record and his pointer... PTMyRec = ^TMyRec; TMyRec = packed record .. .. end; ... and following the protocol implemented in the above mentioned example (server1.zip) I'm trying to send a text command followed by a record. I tried this way from a generic client: var pr : PTMyRec; r : TMyRec; begin wsocket.LineMode := True; WSocket.SendStr(EditCommand.Text + #13#10); // the command is 'DATA ' // r fields filled with some data pr := @r; wsocket.LineMode := False; wsocket.Send(pr, SizeOf(r)); end; On the server, I receive correctly the text command but not the record. What I'm doing wrong? Thank you in advance for your replies. -- Geppy Piloni -- 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] Does THttpCli timeout?
Hello, Real quick question. It is my understanding that THttpCli does not timeout. Say, it has connected to the web server and sent the request. But if the server doesn't send anything back, THttpCli will not timeout. Am I correct? -- Best regards, Jack -- 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] Sending a mix of text and records through TWSocket
Hello Geppy, As Kirk and Arno mentioned show us how you receive the data. maybe one remark at the moment: wsocket.LineMode := True; WSocket.SendStr(EditCommand.Text + #13#10); // the command is 'DATA ' // r fields filled with some data pr := @r; wsocket.LineMode := False; wsocket.Send(pr, SizeOf(r)); Not needed to switch LineMode at the sender. TWSocket will only use lineMode whilst receivin. Also better to work event driven between the 2 applications: - send data whitch tell receiver you want to send a certain binary - receiver set linemode to false and answer 'ok i'm ready' - sender send the binary when he received the 'ok ready' - receiver say 'ok received' and switch lineMode back on - sender can go on now with next command if any on sender lineMode may be switched on all the time as he does only receive line based commands. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Wednesday, October 26, 2005, 19:09, Geppy Piloni wrote: Hi all, I'm trying to implement the client server architecture described here: http://tinyurl.com/benop My first approach was with Indy 10, but after some attempts, I found quite difficult to manage the complexity of multithread programming, so I dropped Indy and now I'm trying ICS. I had a positive experience with ICS HTTP and mail components some years ago and I feel more comfortable with event handling than multithreading... I found a very useful example here http://tinyurl.com/cqkmh , Server1.zip : thank you Wilfried :) I studied also the ICS FAQ about receiving high speed data http://tinyurl.com/762c6 Starting from various TCP client inlcuded in ICS examples, I tried to send through TWSocket a mix of text commands and records but I wasn't successful. Assuming a given record and his pointer... PTMyRec = ^TMyRec; TMyRec = packed record .. .. end; ... and following the protocol implemented in the above mentioned example (server1.zip) I'm trying to send a text command followed by a record. I tried this way from a generic client: var pr : PTMyRec; r : TMyRec; begin wsocket.LineMode := True; WSocket.SendStr(EditCommand.Text + #13#10); // the command is 'DATA ' // r fields filled with some data pr := @r; wsocket.LineMode := False; wsocket.Send(pr, SizeOf(r)); end; On the server, I receive correctly the text command but not the record. What I'm doing wrong? Thank you in advance for your replies. -- Geppy Piloni -- 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] Does THttpCli timeout?
Hello Jack, real quick answer :) correct ! Winsock will timeout after a while, but this is depending on many factors and can take a long time. For automated aplications use your own timeout. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Wednesday, October 26, 2005, 19:24, Jack wrote: Hello, Real quick question. It is my understanding that THttpCli does not timeout. Say, it has connected to the web server and sent the request. But if the server doesn't send anything back, THttpCli will not timeout. Am I correct? -- Best regards, Jack -- 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] Does THttpCli timeout?
Thank you Wilfried and Arno for the real quick replies :) Winsock will timeout after a while, but this is depending on many factors and can take a long time. For automated aplications use your own timeout. Any idea how long it can be? Like, a few minutes? or hours? Real quick question. It is my understanding that THttpCli does not timeout. Say, it has connected to the web server and sent the request. But if the server doesn't send anything back, THttpCli will not timeout. Am I correct? -- Best regards, Jack -- 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] Does THttpCli timeout?
Hello Wilfried, I wonder why would winsock even time out in this case? Isn't it legitimate to have a socket connected and doing nothing? -- Best regards, Jack Wednesday, October 26, 2005, 1:35:36 PM, you wrote: Hello Jack, real quick answer :) correct ! Winsock will timeout after a while, but this is depending on many factors and can take a long time. For automated aplications use your own timeout. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Wednesday, October 26, 2005, 19:24, Jack wrote: Hello, Real quick question. It is my understanding that THttpCli does not timeout. Say, it has connected to the web server and sent the request. But if the server doesn't send anything back, THttpCli will not timeout. Am I correct? -- Best regards, Jack -- 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] Sending a mix of text and records through TWSocket
Starting from various TCP client inlcuded in ICS examples, I tried to send through TWSocket a mix of text commands and records but I wasn't successful. On the server, I receive correctly the text command but not the record. What I'm doing wrong? You would need to be listening with LineMode = false to receive such mixed packets, but you don't really know how long to listen since there is no length sent anywhere. You should really devise a simple protocol that means you know how much data you are sending, and therefore how much to receive. The simplest improvement in your example would be work out the total length of string and record, send that length first, followed by a short string with length byte, then the binary record. Or just move the string into the record (as ShortString). You then know exactly how much data is being received, and can wait for as many packets as it takes. It will not necessarily arrive in a single packet. Angus -- 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] Does THttpCli timeout?
Hello Jack, I wonder why would winsock even time out in this case? Isn't it legitimate to have a socket connected and doing nothing? Yes of course. As always I anser to fast without carefully reading the request :( If yoiu connect and do nothing noone will timeout of course, unless the server or client has a timeout if no data is transmit/rcv. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz -- 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] Does THttpCli timeout?
It is my understanding that THttpCli does not timeout. Say, it has connected to the web server and sent the request. But if the server doesn't send anything back, THttpCli will not timeout. Am I correct? TCP/IP has timeouts for opening a connection, although not usually once the connection is opened. So yes, you do need a timer or triggers based on GetTickCount to timeout a hung open connection. Angus -- 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] TeamICS web page
Ever wanted to know who are the ICS experts taking time to answer your questions ? Just have a look at this page: http://www.overbyte.be/eng/overbyte/teamics.html Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] The author for 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
