Re: [twsocket] 64 bit NNTP Article IDs
Hello! OverbyteIcsNntpCli.pas uses 32-bit number and GetInteger function to convert number to integer rather than StrToInt64. Additionally it uses -1 value as well which further limits the use of 32-bit range. Extending to even 63-bit value (not even need for 64 bit unsigned) as 63 bit integer is still a very very very very large number not likely to be reached anytime soon even in alt.binaries.boneless. How complicated a change to 64 bit article ID's is? Depends on actual application, because on ICS side it should be easy... except it'll probably break a lot of existing code that assumes 32bit article IDs. I did it some time ago and from my experience, it's quite a lot of work, I had to change format of index files, change the code that located articles by their IDs and group management code to accomodate for new boundaries, also it required me to change a bunch of things in configuration dialogs (now they had to take new boundaries into account), ... But that's mostly the application side work. For current versions of Delphi - I think, though I'm not 100% certain - changing integer type from usual integer/cardinal to int64 should be relatively safe. Applications that assume 32bit integers will probably get only a tons of warnings, but should work as long as the actual values are within signed 32-bit integer boundaries. -- Piotr Dałek enigmati...@interia.pl -- 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] PCSensor server/ Simple client-server
Hello! With software supplied with the device, from a Windows PC connected to the same LAN as the TEMPerLAN, I can send a command to it. If the command is BB 82, I get back a short string of ASCII with some data from the device. (Temperatures seen by some attached sensors, but that isn't really central to my question!) So, somehow, their software (it would seem!) is able to send something to the device. The software is first connected (maybe not in the TCP/IP sense) to the device by the device's IP address. (192.168) And then the device sends something out, which is received by the monitoring software. On those slender indications, I certainly don't expect anyone to be able to tell me You just do (this) to duplicate what the software is doing but if anyone has guesses as to the sort of thing that is going on, guesses which could narrow my Google searching, I would be very grateful. Use Wireshark or SmartSniffer (http://www.nirsoft.net/utils/smsniff.html) while running their software to monitor what's transferred between your pc and mentioned device. Also, these programs should tell you on what ports and which protocols (not necessary TCP) data is transferred. -- Piotr Dałek enigmati...@interia.pl --- Nie licz na ZUS, zadbaj o swoja przyszlosc! http://linkint.pl/f2a40 -- 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] Connected when not connected
Hello. In WSocket's DO_FD_CONNECT procedure, the socket state is set to wsConnected even if the socket has failed to connect (for example, on 10061 error), then the SessionConnected handler is called and after that, check for actual error is performed, where socket is closed when error is not zero (like 10061). Im not sure if this is correct - shouldn't be the error checking performed first? I'm asking because I have some code that checks for TWSocket's state to access some of the properties. In some cases it's possible that when socket's State is wsConnect, my code accesses, among other things, GetPeerPort and GetXPort which results in exceptions because socket is not actually connected. -- Piotr Dałek enigmati...@interia.pl - Dzwon tanio! Sprawdz http://linkint.pl/f29a1 -- 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] Connected when not connected
Hello! Hi, This is how winsock works. OnSessionConnected is fired with an error, after it OnSessionClosed is fired with or without an error. So having TWSocket's state different from actual state should be considered normal? If so, then I understand that checking for component state is NOT enough to check whether it is actually connected or not? -- Piotr Dałek enigmati...@interia.pl - Zapytaj wrozke! Sprawdz http://linkint.pl/f29a2 -- 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] Connected when not connected
Hello! This is how winsock works. OnSessionConnected is fired with an error, after it OnSessionClosed is fired with or without an error. So having TWSocket's state different from actual state should be considered normal? If so, then I understand that checking for component state is NOT enough to check whether it is actually connected or not? Well, you should probably consider you are connected with error. The error code being available thru the OnSessionConnected event. So how should I handle connection errors in a way that makes user aware of error AND not cause any kind of disaster? Catch the error code in OnSessionConnected and (using some kind of PostMessage) display actual error message outside OnSessionConnected? -- Piotr Dałek enigmati...@interia.pl - Dzwon tanio! Sprawdz http://linkint.pl/f29a1 -- 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: how to make it listening to
Hello! Now let's assume that application listens on two ip:port pairs, each for different kind of communication. For example, 192.168.1.1:2048 and 192.168.1.1:27015. Also, let's assume that user can define on which ip:port one of servers should listen (another ip:port pair would be fixed). What happens if user enters /192.168.1.1:2048/192.168.1.1:27015/ (for example, because he/she heard/read somewhere that with new ICS this is possible, and the application is based on ICS)? There would be clear conflict between either: - one of server components that now owns both ports and another that attempts to bind to owned port *or* - the second component that correctly owns 27015 port and first component that attempts to bind subservers to both 2048 and 27015 ports (depends on component creation order). This is not different than usual. Any application asking for to listen on a IP:port has to be ready to be refused because the port is already in use. Having multiple IP:port created by a single component doesn't change anything here. The application would handle it exactly the same way. Not quite, because application *doesn't know* that it's going to listen on three (or more) ports (instead of two). While that change doesn't directly break existing code, it might introduce difficult to understand bugs, as seen above. I don't agree with you. The design as I suggest make it totally equivalent to having multiple independant TWSocketServer component with common event handlers. As far as I understand your design well, it's not totally equivalent because it will treat any single bind failure as a total disaster, even if another binds are meant to be spare and actually not required to function (failure to bind on other ip:ports is not considered fatal). -- Piotr Dałek enigmati...@interia.pl Nie polegaj na drogowcach #8211; sam zaskocz zimÄ i ZMIEĹ OPONY! SprawdĹş http://linkint.pl/f286e -- 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: how to make it listening to
Hello! Hello all, Since the Addr property is a string, the component could easily handle any special format in that field to support multiple listening IP:Port (Interface to listen to and port to use on that interface). I think something like /192.168.1.1:80/0.0.0.0:81/. IPv4 or IPv6 could be used. The component can easily find out that there is a multiple IP:Port because of the / at the beginning. The port property would be used as default value when no prot is specified in the Addr for a given IP. As an example: Addr := /192.168.1.1/192.168.2.1/10.1.2.3:80/ and Port := 81 would make listening on port 81 for 192.168.1.1 and 192.168.2.1, and listening on port 80 for interface 10.1.2.3. Now let's assume that application listens on two ip:port pairs, each for different kind of communication. For example, 192.168.1.1:2048 and 192.168.1.1:27015. Also, let's assume that user can define on which ip:port one of servers should listen (another ip:port pair would be fixed). What happens if user enters /192.168.1.1:2048/192.168.1.1:27015/ (for example, because he/she heard/read somewhere that with new ICS this is possible, and the application is based on ICS)? There would be clear conflict between either: - one of server components that now owns both ports and another that attempts to bind to owned port *or* - the second component that correctly owns 27015 port and first component that attempts to bind subservers to both 2048 and 27015 ports (depends on component creation order). While that change doesn't directly break existing code, it might introduce difficult to understand bugs, as seen above. One workaround I see now is to filter the user input, but that adds new code to equation. Another, and what I think the most reasonable, is to create a new class derived from TWSocketServer that would accept such input and leave original TWSocketServer untouched. Just my 5€. -- Piotr Dałek enigmati...@interia.pl -- Chcesz wiÄcej zarabiaÄ? ZmieĆ pracÄ na lepszÄ ! http://linkint.pl/f2849 -- 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] OpenSSL 1.0
Hello! Hi, IcsSSL is compatible with OpenSSL 1.0 ? now i'm using 0.9.8e, do you suggest me to update to version 1? thank you in advantage. I had some problems related to ciphers/TLS when using OpenSSL 1.0 - at least with the build provided by Shining Light Productions. With OpenSSL 0.9.8 build provided by ICS team I had no problems. But it might be related to what is actually built into both builds, because when everything was set to defaults and nothing was enforced, both versions were good for me. BTW: OpenSSL has some fancy ciphers and hash routines built in, one can use them instead the ones provided by ICS itself and gain sometimes huge performance advantage. -- Piotr Dałek enigmati...@interia.pl http://www.hellcore-mailer.pl -- Najlepsza wyszukiwarka tanich lotow! Sprawdz http://linkint.pl/f27c3 -- 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] Proposal for more contenttypes in DocumentToContentType in OverbyteIcsHttpSrv.pas
Hello! else if (Ext = 'doc') or (Ext = 'docx') then Result := 'application/msword' else if (Ext = 'xls') or (Ext = 'xlsx') then Result := 'application/vnd.ms-excel' else if (Ext = 'ppt') or (Ext = 'pptx') then Result := 'application/vnd.ms-powerpoint' In my opinion, such things shouldn't be kept in component's source code. There should be external (or stored as resource) configuration file that contains all extension-content type pairs. -- Piotr Dałek enigmati...@interia.pl -- Wygraj telefon HTC Touch Diamond 2. Sprawdź http://link.interia.pl/f233f -- 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] Package Count / Wireshark
Hello! i used wireshark to monitor activity on the port i m listening on.Protocol is TCP and the server was build with ICS TWSocketServer. Monitoring packages arrived, I see that one of the packages (505 byte) is divided into 3 packages. What i want to ask; is this the way tcp protocol transfers data over network, or package count is because of the method client uses to send data..? Depends. Packet size is typically limited to ~1500 bytes, can go up to few kilobytes if jumbo frames are enabled. Regardless, depending of through what your data have come, they can be split into smaller packets (that's called packet fragmentation). Also, if sending side disables Nagle algorhitm (sets tcpNoDelay flag), data are sent immediately - one packet per one send call. If that flag is not set, data are sent only after filling up a packet or after a few miliseconds of pause between send's. Can we make a package transfered in a whole (in size limitations) or tcp decides how to transfer data by itself? Between sending and receiving side there may be a router or bridge that can't handle certain packet sizes. At this point your packets might be split into two or more. The reason i am in this case is not the package count, but the headers used to form a package which makes data count increase.. See above. Either don't disable Nagle algorithm or send in large chunks. As receiving side, you can't do anything to reduce packet count. (as a side note, in client-server request-response scenarios, packet count can be dramatically reduced by utilizing pipelining, that is - sending all requests in one go and then waiting for responses instead of sending single request, waiting for response, sending another request, ... and so on; for POP3/NNTP protocol you usually can fit all your RETR/ARTICLE requests in just one outgoing packet). -- Piotr Dałek enigmati...@interia.pl -- Praca za granicą? Zobacz oferty! http://link.interia.pl/f2331 -- 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] Ipv6
Hello! No, not as long as there are people using and supporting it actively. However users will move to another component suite when they need basic features not included in ICS. IMO IPv6 will become such a basic feature rather soon. Competitors of ICS already support IPv6. And IMAP4 : -- Piotr Dałek enigmati...@interia.pl -- Bezpłatne konto? Otwórz tutaj! http://link.interia.pl/f225a -- 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] FileMD5 : Different Hash Result - same
Hello! ineic...@triple-m.ch wrote: Face this: On this client some files (not all!) had a different md5 hash. But this everytime with all tools! After a while i did a reboot - and guess: everything was as expected. Maybe Piotr was right with some harware issue. Very very strange! Yes, this looks like a RAM issue, if so the computer or applications should crash or fail randomly as well and files could get corrupted. I suggest you run Memtest86 from http://www.memtest.org/ or http://www.memtest86.com/. [..] Or Google for OCCT or StressPrime. These tools should help, too. -- Piotr Dałek enigmati...@interia.pl -- Dobra czy zla wiadomosc? Zawsze warto oszczedzac. Teraz 5,5%. Sprawdź http://link.interia.pl/f221b -- 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] FileMD5 : Different Hash Result - same File ondifferent workstation
Hello! Thank you all, I tried it with v6 and after that with v5 (using Delphi 2007). Unfortunately i do not have remote access to this client. Tomorrow i i'll go there and try with: - ICS v7 - The suggested tool - using a test app with indy (i'll do it this night) i'll come back to you This *might* be also a sign of corrupted RAM or failing motherboard, especially if you get different hashes every time. -- Piotr Dałek enigmati...@interia.pl -- Przekaz dalej wiadomosc: Zawsze warto oszczedzac. Teraz 5,5%! Sprawdz http://link.interia.pl/f21b1 -- 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 Digest, Vol 321, Issue 4
Hello!
On Tue, 12 May 2009 12:00:01 +, you wrote:
Possibly you need breaks? :-)
switch(RqType)
{
case smtpConnect: SMTP-Helo(); break;
case smtpHelo: SMTP-MailFrom(); break;
case smtpEhlo: SMTP-Auth(); break;
case smtpAuth: SMTP-MailFrom(); break;
case smtpMailFrom: SMTP-RcptTo(); break;
case smtpRcptTo: SMTP-Data(); break;
case smtpData: SMTP-Quit(); break;
}
No. Tried this too. The breaks has no effect in this switch
( No default value )
See this:
http://www.cppreference.com/wiki/keywords/switch
--
Piotr Dałek
enigmati...@interia.pl
--
Dzwonki na komorkę!
Sprawdz http://link.interia.pl/f2161
--
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] TIcsLogger proposal
Hello! LogColumnSeparator is also useful. It is clear that having a separate date format and time format is not required. A single format string is enough because one can add the LogColumnSeparator that format string (anyway, that's what Anton's code do by concatenation dateformat, columnsep and time format). That's true, but concatenating strings is slow and should be avoided whenever possible. In Anton's change there are three properties to form a simple DataTime string including the separator, this should be simplified IMO. Format could be used instead of concatenation. -- Piotr Dałek enigmati...@interia.pl -- Wygraj 3000 zl, wycieczke lub lot balonem! Sprawdz http://link.interia.pl/f2154 -- 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] TIcsLogger proposal
Hello! That's true, but concatenating strings is slow and should be avoided whenever possible. In Anton's change there are three properties to form a simple DataTime string including the separator, this should be simplified IMO. Format could be used instead of concatenation. Format is and has been always used. However the format string must IMO not be concatenated before the call to FormatDateTime unless speed doesn't matter. Then concatenate it once in property's setter. -- Piotr Dałek enigmati...@interia.pl -- Dzwonki na komorkę! Sprawdz http://link.interia.pl/f2152 -- 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 trying to download from a website
Hello!
[..]
procedure TSplashForm.HttpCliDocEnd(Sender: TObject);
begin
if HttpCli.RcvdStream nil then begin
HttpCli.RcvdStream.Free;
HttpCli.RcvdStream := nil;
end;
end;
procedure TSplashForm.HttpCliRequestDone(Sender: TObject;
RqType: THttpRequest; ErrCode: Word);
var
i: integer;
sl: TStringList;
b: Boolean;
sReleaseDate: string;
begin
if ErrCode = 0 then
begin
sl := TStringList.Create;
sl.LoadFromStream(HttpCli.RcvdStream); AV here
[..]
What am I doing wrong?
Probably you're freeing destination stream before using it. Put something
like
if HttpCli.RcvdStream=nil then
ShowMessage('RcvdStream is NIL, click OK to crash.');
before sl.LoadFromStream(HttpCli.RcvdStream); to check whether that's the
case.
--
Piotr Dałek
enigmati...@interia.pl
--
Zyskaj tak jak ja 9% na lokacie w pierwszym miesiacu!
Sprawdz! http://link.interia.pl/f207b
--
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] MboxProxy available for download
Hello! Interesting stuff, but your site looks down... Works for me. (?) Direct URL: http://branchware.ovh.org/files/mboxproxy.7z (123kB) -- Piotr Dałek enigmati...@interia.pl -- Promocja w Speak Up. Kurs angielskiego za darmo. Liczba miejsc ograniczona. Sprawdź! http://link.interia.pl/f205c -- 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] MboxProxy available for download
Hi! MboxProxy is a small program which - acting as a POP3 server - allows you to import messages from Unix MBOX files to _any_ e-mail program (supporting POP3 protocol). MboxProxy is a better solution than Hamster mainly because with MboxProxy it takes far less time (no adding messages to local database). Moreover, MboxProxy has far better performing network code, what makes it great pop3 client benchmarking tool. It has come to my attention that there's more than just a few people having trouble moving his/hers mail from (mainly) Thunderbird and find MboxProxy very helpful tool, so I translated UI and readme file. The reason I post this here? MboxProxy is written in Borland Delphi with ICS, and included in .7z file is complete source code, so you may learn how to write servers (especially POP3 servers) with ICS. You may get it from http://branchware.ovh.org. Please send any mail regarding MboxProxy directly to me (email below). -- Piotr Dałek enigmati...@interia.pl -- Promocja w Speak Up. Kurs angielskiego za darmo. Liczba miejsc ograniczona. Sprawdź! http://link.interia.pl/f205c -- 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 ~ firewall software problem
Hello! It has nothing to do with the old version imho. I'm using V7 and have the same problem. I have TrendMicro installed and the new version is quite agressive. If I compile a keyhook that I wrote myself, it blocks even the compiler ! The only thing that helps is switching off the firewall or digitally sign all the executables and dll's. The creators of the firewalls forgot that there are still people writing software ... I'm using a Comodo Personal Firewall without any problems. At least with POP3, SMTP and NNTP (with and without SSL), I don't use any other ICS components. Once I added my apps to trusted applications, I have no problems with recompiling and running them from IDE or standalone. -- Piotr Dałek enigmati...@interia.pl --- Promocja w Speak Up. Kwartal angielskiego za darmo. 3 miesiace nauki gratis. Sprawdz teraz! http://link.interia.pl/f2019 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Pause and Resume just not working!
Hello! Hello ICS Mailinglist, this is a bugreport that on localhost the windows kernel reads megabytes of data before a TWSocket client can block. As you can see on the following explanation and the images on http://projekte.priv.de/ics_localhost_bug/ , the problem is the windows kernel: No. The problem is that you don't understand how ICS work. By this: transfered := socket.Send(@buf, sizeof(buf)); assuming buf: array[0..102400] of byte; you command ICS TWsocket to send 102401 bytes. It doesn't necessarily mean that it goes straight to Windows Sockets (or TCP/IP stack, whatever). Now, in TWSocket.Send, component splits your data (these 102401 bytes) into ~1,5 kilobyte chunks, puts every chunk into FIFO (first-in-first-out) queue, enlarging it, then sends every chunk one-by-one, shrinking the queue. Component sends data to TCP/IP stack as long as this doesn't err out (ie. send() doesn't return error Operation would block - or any other error - what may happen when, for example, destination socket doesn't consume sent data). When you do .pause on receiving (*NOT* sending) socket, you say ok, now I don't want to know that new data have arrived. Meanwhile, sending TWSocket component *still* send data to TCP/IP on his side, TCP/IP sends data to destination socket, TCP/IP on the destination side sees that socket doesn't consume data so it buffers them as long as there's enough space for this (see SO_RCVBUF), and when buffer is full, it responds to sending side with some kind of sorry, i cannot handle more data, you're talking too fast. Sending socket, seeing this, responds to queue pumping code (within TWSocket) with Operation Would Block, what makes FIFO in TWSocket stop shrinking. That's why memory usage of sending application skyrockets: receiving side doesn't receive data (because it doesn't want to know that data have arrived), and sending side is not aware of this. Why? Because you just say send! send! send! send it goddamnit! send it!!! not checking whether something has actually been sent *and* received. You have OnDataSent for this purpose - it's fired when TWSocket sending FIFO queue is emptied successfully. To cut things short - by using TWSocket's send method, you say put these data in your buffers, send it to the other side, and tell me, by firing OnDataSent, when you've dealt with that.. If you use send again - before having received OnDataSent event - you say hey, I have some more data to send, send them when you'll deal with all previous data, and tell me, by firing OnDataSent, when you'll send *all* data - the previously ordered to send *and* the new data. HTH. -- Piotr Dałek enigmati...@interia.pl -- Kochanka - kobieta drugiej kategorii? sprawdz http://link.interia.pl/f2026 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Pause and Resume just not working!
Hello! HI Piotr Dałek, yes you are right with your argumentation. I am using TWSocket in a manner generally not allowed, cause message processing and so on is not assured. And we can stop right here. Since I'm a ICS V5 user, I cannot answer to your but's - maybe something has changed in ICS V6, but anyway don't expect any predictible behavior when you're not using things right. -- Piotr Dałek enigmati...@interia.pl -- Sprawdz, co wyswietlaja kina w Twoim miescie! http://link.interia.pl/f2028 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] OverbyteIcsMimeUtils.pas - DoFileEncBase64
Hello! A reliable way to calculate More was More := Stream.Position Stream.Size; however that is slower since Stream.Size has to seek to the end of the stream and the back to current position on each call of DoFileEncBase64(). (Instead of Stream.Size we could also check against file size, however only with ShareMode fmShareDenyWrite). var LocalStreamSize: integer; [..] LocalStreamSize := Stream.Size; [..] More := Stream.Position LocalStreamSize; [..] Problem solved. -- Piotr Dałek enigmati...@interia.pl -- Zobacz program TV na dzis! sprawdz http://link.interia.pl/f202a -- 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] OverbyteIcsMimeUtils.pas - DoFileEncBase64
Hello! Piotr Dałek wrote: Hello! A reliable way to calculate More was More := Stream.Position Stream.Size; however that is slower since Stream.Size has to seek to the end of the stream and the back to current position on each call of DoFileEncBase64(). (Instead of Stream.Size we could also check against file size, however only with ShareMode fmShareDenyWrite). var LocalStreamSize: integer; [..] LocalStreamSize := Stream.Size; [..] More := Stream.Position LocalStreamSize; [..] Problem solved. I do not get this, sorry. Please elaborate. Get the stream size only once - store it somewhere and use stored value instead of calling Stream.Size getter. -- Piotr Dałek enigmati...@interia.pl --- Promocja w Speak Up. Kwartal angielskiego za darmo. 3 miesiace nauki gratis. Sprawdz teraz! http://link.interia.pl/f2019 -- 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] OverbyteIcsMimeUtils.pas - DoFileEncBase64
Hello! A reliable way to calculate More was More := Stream.Position Stream.Size; however that is slower since Stream.Size has to seek to the end of the stream and the back to current position on each call of DoFileEncBase64(). (Instead of Stream.Size we could also check against file size, however only with ShareMode fmShareDenyWrite). var LocalStreamSize: integer; [..] LocalStreamSize := Stream.Size; [..] More := Stream.Position LocalStreamSize; [..] Problem solved. I do not get this, sorry. Please elaborate. Get the stream size only once - store it somewhere and use stored value instead of calling Stream.Size getter. OK, but what will happen if the stream size changes during encoding, if for instance the component user opened the file with ShareMode fmShareDenyRead? That's why I added public property Mode to the TBufferedFileStream class and check the ShareMode in DoFileEncBase64,. in case of no problem TBufferedFileStream(Stream).FastSize is called (which is current, constant size), otherwise Stream.Size (which is slow, but who will actually open a file to be sent with ShareMode fmShareDenyRead only ? I guess not many). The only reason for this is creating attachment (file to be encoded) while it is actually encoded, but then, using the mechanism available in ICS is a waste of disk space (already encoded original data still reside on disk). I think that all users will use simple files containing ready data that is not going to be changed during encode process. Supporting other scenarions is overkill, at least for me. If you don't agree, then what if you buffer (in TBufferedFileStream) 1024 bytes, encode first 50, then (somehow) next 100 bytes changes? You still have outdated 100 bytes in the buffer. Then what? Bug, no matter what! So why should you care about size change, if you don't care about actual file changes? I don't think that you're going to support *that* scenario. -- Piotr Dałek enigmati...@interia.pl -- Promocja w Speak Up. 3 miesiace angielskiego gratis. Sprawdz teraz i wypelnij formularz! http://link.interia.pl/f2019 -- 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: openssl
Hello! I need to convert a .pfx certificate to .pem format. I use openssl.exe, but it doesn't allow anything to type on message Enter password Only pressing Enter Anyone knows what the problem is here ? Probably it simply doesn't print what you type. Try blind-typing proper password and pressing enter. -- Piotr Dałek [EMAIL PROTECTED] Dzwon tanio do wszystkich! Sprawdz http://link.interia.pl/f1f93 -- 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] Proposal to replace TIniFile by TRegIniFile in all
Hello!
Hi,
Since Delphi and ICS goes Unicode I suggest to replace
TIniFile by TRegIniFile in all demo applications.
TInifile uses Win32 API functions which do not support
Unicode, any string is converted to ANSI implicitly.
TMemIniFile won't be a solution since Delphi 2009 UPD 1
did not fix a bug with UTF-8, even if TMemIniFile was able
handle UTF-8 correctly, how would you manually maintain,
for example, a UTF-8 file name?
So I suggest to use the registry with a key under HKCU
Software\FPiette\ICS\Demos\ instead, thast would resolve
problems with UAC in Vista as well.
What do you think?
I didn't follow the thread, but in my opinion, the easiest and the least
enterprisey solution could be encoding to UTF-8 all values passed to
WriteString and decoding from UTF-8 all values obtained by ReadString.
No need to switch to TRegIniFile or (DOH!) XML files.
For example:
IniFile.WriteString('Settings', 'LastFile', UTF8Encode(filename));
filename:=UTF8Decode(IniFile.ReadString('Settings', 'LastFile', ''));
--
Piotr Dałek
[EMAIL PROTECTED]
--
Konkurs! Wygraj telewizor LCD!
Sprawdz http://link.interia.pl/f1f61
--
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] Can't send data with SSL enabled
Hi! This drives me crazy. I can estabilish standard, unencrypted connection with any non-SSL server and successfully transfer data, and I can estabilish unencrypted connection, estabilish SSL/TLS session (via means similiar to STARTTLS in POP3/SMTP), then communicate in both ways. But if I want to estabilish direct SSL/TLS (not STARTTLS) connection, I succed only in handshaking and receiving first server's response after SSL handshake - ie. the first line (banner) after handshaking. Then I can't send anything. No matter what I use, data are sent to buffers, my_BIO_ctrl([..] BIO_CTRL_FLUSH [..]) returns success but data aren't really sent (checked with external sniffer), and I get no notification of data being sent out. SSL'ised versions of TPop3Cli and TSmtpCli don't work either. Any ideas what may be wrong? I'm struggling with this for two days now. ICS V5. -- Piotr Dałek [EMAIL PROTECTED] -- Notowania GPW w telefonie! Sprawdz http://link.interia.pl/f1f37 -- 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] Can't send data with SSL enabled
Hello! Piotr Dałek wrote: Hi! This drives me crazy. I can estabilish standard, unencrypted connection with any non-SSL server and successfully transfer data, and I can estabilish unencrypted connection, estabilish SSL/TLS session (via means similiar to STARTTLS in POP3/SMTP), then communicate in both ways. But if I want to estabilish direct SSL/TLS (not STARTTLS) connection, I succed only in handshaking and receiving first server's response after SSL handshake - ie. the first line (banner) after handshaking. Then I can't send anything. No matter what I use, data are sent to buffers, my_BIO_ctrl([..] BIO_CTRL_FLUSH [..]) returns success but data aren't really sent (checked with external sniffer), and I get no notification of data being sent out. SSL'ised versions of TPop3Cli and TSmtpCli don't work either. Any ideas what may be wrong? I'm struggling with this for two days now. Have you tried the SslMailSnd demo yet? If not please try. Already tried, doesn't work. I just tested with gmail succesfully. Is this ICS v6? ICS V5. -- Piotr Dałek [EMAIL PROTECTED] -- Szukasz mieszkania, domu dzialki? Sprawdz http://link.interia.pl/f1f47 -- 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] Converting memorystream to string?
Hello! procedure LoginSocketDocEnd(Sender: TObject); var p: PChar; s: string; begin p := TMemoryStream(LoginSocket.RcvdStream).Memory; s:= Copy(StrPas(p), 1, LoginSocket.RcvdStream.Size); This will crash if source TMemoryStream doesn't end with #0. Moreover, this copies data twice (wastes time and memory). Use this: SetLength(s, LoginSocket.RcvdStream.Size); Move(TMemoryStream(LoginSocket.RcvdStream).Memory^, pointer(s)^, LoginSocket.RcvdStream.Size); -- Piotr Dałek [EMAIL PROTECTED] -- Prosty kredyt na wszystkie potrzeby. Od 1000 zl do 120 000 zl. Bez poreczycieli i zabezpieczen http://link.interia.pl/f1edf -- 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] Interesting multithreading issue: race condition when triggering an event handler
Hello! I've found an interesting multithreading issue which is related not only to ICS component but many many other components I've seen so far. It is a race condition between two thread where one is triggering an event handler and the other is removing (setting to nil) the event handler. [..] Quite normal. The proper way to disable a handler is not nil'ing it nor grabbing and saving pointer to handler proc and then calling it (because then the thread1 may do something that thread2 don't want do), but using a global, protected by critical section variable. But the best solution is to not nil any handler in another thread, ie. use a logic that doesn't require such actions. -- Piotr Dalek [EMAIL PROTECTED] -- PS. Fajny portal... http://link.interia.pl/f196a -- 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] Interesting multithreading issue: race condition when triggering an event handler
Hello! I've found an interesting multithreading issue which is related not only to ICS component but many many other components I've seen so far. It is a race condition between two thread where one is triggering an event handler and the other is removing (setting to nil) the event handler. [..] Quite normal. The proper way to disable a handler is not nil'ing it nor grabbing and saving pointer to handler proc and then calling it (because then the thread1 may do something that thread2 don't want do), but using a global, protected by critical section variable. Sorry but I don't agree with you. The only proper way to disable an event handler is to nilling it. Only in case of single-threades applications or multithreaded ones that do not use one component in several, parallel threads. Using a global variable is a very bad design or even wrong design: you may have many instances of the same component. You can still use a descendant with another public field. Protecting using a critical section doesn't solve anything in that case and would have a negative impact on performance. Of course it does! procedure TMyComponent.TriggerMyEvent(MyArg : Integer); begin EnterCriticalSection(SomeSection); if Assigned(OnMyEvent) then OnMyEvent(Self, MyArg); LeaveCriticalSection(SomeSection); end; Now we're certain that nothing would change OnMyEvent between the if...then and OnMyEvent call, and old OnMyEvent won't be triggered even if thread2 would nil it in-between if..then and OnMyEvent - thread2 will nil it AFTER OnMyEvent occurence. It is thread's #2 responsability to handle the consequences of nilling the event handler. The component having an handler nilled can trigger an null pointer exception because of that but is not responsible for what happend outside of his own code. True, but what if thread2 nils the event handler AFTER thread1 saves the event handler's procedure address? Thread2 may do this because of something happened - something that requires the event to NOT occur. Now Thread1 has saved the event handler address, Thread2 is certain that the event won't occur, and voila - event occurs anyway. This may lead to difficult to debug bugs. The only way to not complicate code and slow it down due to critical section usage is to NOT nil events on which *other* thread relies. Otherwise thread2 should enter critical section, nil it, and leave it. Your solution isn't bad, it simply can cause some confusion if someone relies on events not occuring. -- Piotr Dalek [EMAIL PROTECTED] -- PS. Fajny portal... http://link.interia.pl/f196a -- 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] HTTP/1.1 pipelining--any need?
Hello! If you look at the rfc, the requests are meant to be executed serially. The responses must be provided in the same sequence as the requests. This doesn't mean that each request can't be executed by a separate thread. As I said, responses has to be serialized to be sent in the correct order. But this doesn't make much sense in common case. Having more than one thread for a single client (additional to single thread for every client) will make thread switching and synchronization stuff the server's bottleneck, not mentioning the code obfuscation. This may, however, be a good thing when requests are done externally (for ex. a call to SQL server on another machine) and while they're completed the HTTP server doesn't do anything useful, but then again - we don't need separate threads to achieve that. -- Piotr Dalek [EMAIL PROTECTED] -- PS. Fajny portal... http://link.interia.pl/f196a -- 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] Message-Id is not valid, according to RFC 2822
Hello! Is there something I can do to pacify X-Spam? Remove that space (the one between Roland and Couvela). Shall we modify function GenerateMessageID? Something like: Do whatever you please... -- Piotr Dalek [EMAIL PROTECTED] -- PS. Fajny portal... http://link.interia.pl/f196a -- 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] Message-Id is not valid, according to RFC 2822
Hello! Thank you, Arno, for your help, project now working, but on sending myself a message I get back X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on as002.apm-internet.net X-Spam-Report: * 1.7 INVALID_MSGID Message-Id is not valid, according to RFC 2822 [..] Message-ID: [EMAIL PROTECTED] Couvela [..] Is there something I can do to pacify X-Spam? Remove that space (the one between Roland and Couvela). -- Piotr Dalek [EMAIL PROTECTED] -- PS. Fajny portal... http://link.interia.pl/f196a -- 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 V6 Http Post problem
Hello! I always loved the Pascal way of obfuscating code with those complicated mix of @ pchar ^ and other funny notation as soon as you need to play with pointers and direct data memory access... It's complicated only when you don't use it often. Otherwise it requires a bit more attention than usual things like a:=b. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Auto kontra pociag: efekt konfrontacji! http://link.interia.pl/f1921 -- 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] Server problem (leaking memory)
Hello! I saw some leaks in older Delphi versions when I didn't finalize (may be due a mistake I made when I was a beginner?). Seems so. Here (D3Prof) everything works properly, no leaks. Since this time I don't really on Delphi and free dynamic record members manually. And you don't get AVs and/or Invalid Pointer Operation exceptions? -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- 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] Server problem (leaking memory)
Hello! Since this time I don't really on Delphi and free dynamic record members manually. And you don't get AVs and/or Invalid Pointer Operation exceptions? No problemo. Finalize(P^); or AString := ''; Dispose(P); Hint: Dispose acts as Finalize+FreeMem. No need to finalize records allocated by New(). -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- 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] twsocket cpu usage
Hello! Is there a way to limit the cpu usage when receiving files thru TWsocket? Usualy CPU is 90-100% used and the computer freezes for the time the transfer is made. If you write in a random sized chunks (especially byte-per-write), use some kind of write-buffering filestream (AFAIR Arno has coded one). If that won't help you much, insert sleep(0); *before* call to write/writefile/blockwrite/etc. Inserting your code into separate thread won't help you if you're experiencing *computer* (not program!) freezes. Also, don't use dynamically-sized memory streams and memory buffers (like dynamic arrays, note that long string is also a kind of dynamic array, and concatenating strings is a kind of dynamic resize of an array), you won't get any benefits, only trouble (like wasting time for memory reallocation and having memory fragmented). If you need buffer, use static one (like pre-allocated array). -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Kliknij po wiecej! http://link.interia.pl/f18ed -- 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] Charset in Mail header
Hello! Is it possible, what I want to do? Because, now I have in header line like this: Content-Type: multipart/related; type=multipart/alternative; boundary==_NextPart_000_0048BF3A_0.5597F664 But, I need to add something like this: Content-type: text/html; charset=iso-8859-2 If I add this line to procedure HtmlSmtpClientProcessHeader it brokes the email... You don't understand the basics of MIME! Current THtmlSmtpCli does send mail in dual format, that is - your message is in both plain text and HTML formats. You need to set proper charset declaration in a headers of *both* format types (or at least HTML format), but not mail header (as you do right now!). -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- 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] Running on W95
Hello! Found update for sr1 and winsock 2 for W95 on the microsoft-pages. First hit after searching for winsock on the download-page. After upgrading, ICS works again. For my part I think it's ok that it works if the updates are aplied. Installing Winsock 2 is a good idea also for other reasons, like security fixes. :) -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] Taaakie auto! http://link.interia.pl/f1910 -- 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] Running on W95
Hello! You already know what was the problem, but I'll answer this one anyway: version of winsock.dll located in your %windir%. If it is 4.00.950, you've got Winsock 1, Winsock 2 is 4.10.1656 (at least at my Win95 installation). My winsock.dll is version 4.00.. If what you say is correct, then my version seems to be even older than 1.1. No, 4.00.950 (4.00.0950, not 4.00.9500) is Winsock 1.0, 4.00. may be Winsock 1.1. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] Taaakie auto! http://link.interia.pl/f1910 -- 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] Running on W95
Hello! I have trouble with running an exe that uses the the THttpCli component on a W95. It works on W98 and later. And it works also on earlier versions of ICS, but not the latest beta. I get this error-message in ReasonPhrase in OnRequestDone: Can't connect: No error (Error #0) Anyone has any tips? Try upgrading Winsock to Winsock 2. Because currently almost nobody really cares about backward compatibility (unless it requires abnormal 10% brain usage and spending five minutes more on upgrading sources), there's a big chance that nobody noticed that something may require Winsock 2 to work. To see whether you already have it or not, you may want to check version of winsock.dll located in your %windir%. If it is 4.00.950, you've got Winsock 1, Winsock 2 is 4.10.1656 (at least at my Win95 installation). I'm not sure, but checking whether your app requires too high version of winsock (as Francois noted) may also help. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Kliknij po wiecej! http://link.interia.pl/f18ed -- 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] OT: ICS' position on Borland sale
Hello! Whenever Delphi is sold I think actual version of Delphi and ICS will permit to continue make programs for some years. Exactly. Since Delphi isn't some kind of interpreter and also isn't closed environment, extending RTL to accomodate OS changes is still possible. If there will be no Delphi for Win64, support for Win32 apps in Win64 will still allow to be both backward and forward compatible (pcs with Win32-only OS will remain for - IMO - at least 5-8 years after Win64 release date - of course if not longer, Win16 PCs are still here - 11 years after Win95 release). So in my opinion there's no need to worry - for now at least, ince there's no Win64 at all (and Microsoft still delays the Vista release). 6 years is a whole lot of time, and should be enough to find another IDE - Not necessarily M$ one - learn it, and port living projects to it. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Ocen dziewczyny Playboya!!! http://link.interia.pl/f190f -- 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 directly, not via Send Buffer
Hello! Yes, I'm going to use such long delimiter because I need to send binary data... If you're sending binary data, don't play with delimiters, but send the data size first (as a 4-byte longint), then actual data. Client first waits for data size, then waits for the data_size bytes and stores them. Simple, fast and reliable. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] Jestes poszukiwany. Szukaja Cie imprezowicze! http://link.interia.pl/f190a -- 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] Reverse DNS lookup failure
Hello! www.microsoft.de resolves to 207.46.130.108 and 207.46.250.119 WSocket.ReverseDnsLookup(207.46.130.108/207.46.250.119) as well as NSLookup fails, tested with multiple name servers. Does somebody know why? But http://www.dnsstuff.com/ returns 15 records. C:\WINDOWS\Profiles\Piotrek\Pulpitping www.wp.pl Pinging www.wp.pl [212.77.100.101] with 32 bytes of data: Control-C C:\WINDOWS\Profiles\Piotrek\Pulpitping -a 212.77.100.101 Pinging www.wp.pl [212.77.100.101] with 32 bytes of data: Control-C C:\WINDOWS\Profiles\Piotrek\Pulpitping -a 207.46.250.119 Pinging 207.46.250.119 with 32 bytes of data: Control-C Seems like dnsstuff.com may have more nameservers or their own database. Since it doesn't work with simple ping -a too, I wouldn't worry about this. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] --- Fotoerotica! http://link.interia.pl/f1904 -- 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] Reverse DNS lookup failure
Hello! PD Seems like dnsstuff.com may have more nameservers or their own database. PD Since it doesn't work with simple ping -a too, I wouldn't worry about PD this. I only see thoses two IPs from dnsstuff.com, which field/option did you use ? To be honest, I didn't used dnsstuff.com - I just did a quick check with a ping tool. I assumed that if Arno saw any entries on dnsstuff.com, then they're at least there. If they aren't, .. well, better for us, since then the problem actually doesn't exist. :) -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Kliknij po wiecej! http://link.interia.pl/f18ed -- 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 and MidWare Frappr group
Hello! Sure their privacy policy of the day say they won't spam, but it also says We reserve the right to change our privacy policy at any time If they change their policy, this would apply only to the data they collected after their change. Well... Microsoft also writes everywhere that Windows is so fast, reliable, secure and so on, but unfortunately life shows that this isn't true. Same here. They may say they won't spam, but some day you could start receiving unwanted messages - just because you've signed up to some funny project. Some time ago I've been playing with counters (those thingys you put on website to count visitors), and found one that requires you to enter your email (to receive HTML code), and *password* - what for, if there were no login option? So I entered stupid abc - and that was great idea, because counter's server admin was lame kid and believed that he could login into provided account using provided password (using same password more than once isn't a good idea anyway, but many don't care!). Since admin of server where I've had that mail account was my friend, he called me and asked why I've tried to login with some weird password *few times* - yes, that lamebrain used abc as password to my mailbox... Anyway, the mailing list is indexed by google, so your email is already referenced by google. [..] You are well known on the internet. I'm sure you already receive a lot of spam as I do (hundreds of messages each single day). That doesn't mean he want to receive more spam. I don't get much spam messages (1-2 per *month* on this account, 1-2 per day on other account that was heavily used on usenet few years ago (!)), and I'd like to keep it on that level. Thanks to antispam system on poczta.interia.pl (and small obfuscation of email address in usenet postings), most of the known spam doesn't even come through their SMTP - unfortunately, some wanted messages (mostly those from Yahoo!Groups) also don't, but that's not a big issue for me anyway. In other words - don't force anyone to be happy. Things that may be funny for you may not be funny for others (if I'd like to play with Frappr, I'd use other mail account). Dropping D3 support is enough for me. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Kliknij po wiecej! http://link.interia.pl/f18ed -- 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 and MidWare Frappr group
Hello! Sure their privacy policy of the day say they won't spam, but it also says We reserve the right to change our privacy policy at any time Just use an e-mail address you can 'burn' if necessarry. I couldn't. Nobody allowed me to choose the address. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Kliknij po wiecej! http://link.interia.pl/f18ed -- 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] (no subject)
Hello! -l 1472 works for WAN machines (ie. .wp.pl), but not localhost nor LAN. It works here with Win-XP PRO SP2. So one of solutions is moving to WinXP Pro with SP2. No other reasonable solutions? ;-) I'll be googling more for this W95+Winsock2 feature later. Maybe I'll finally find out what's going on. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Kliknij po wiecej! http://link.interia.pl/f18ed -- 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] (no subject)
Hello! Strange. Maybe your local MTU is set to 512 because of the dialup ? PPP is defaut 512 bytes. I thought so too, but removing PPP didn't changed things. So I assumed that there's some unreverted changes in Winsock settings - I've changed appriopriate settings multiple times for multiple values, and it didn't worked anyway. That's unfair! ;-) Hopefully you didn't use one of those buggy optimizers available on the net. They may more hurt than they help. No, I did not. I'm smart enough to see that I don't need any fancy optimizer to edit some registry settings (what includes making a safety backup - the one that has saved my '95 twice). Now I'm wondering how that small packet size affects connection to servers on localhost (which I use for debugging and profiling purposes). Hopefully it isn't too bad... -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Kliknij po wiecej! http://link.interia.pl/f18ed -- 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] (no subject)
Hello! Pinging 195.130.132.82 with 1473 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. As you see, my largest possible packet size is 1472. Adding 28 bytes of ICMP and IP headers I see my MTU is 1500. I am pretty sure you will have exact same result. Well, then see this: C:\WINDOWS\Profiles\Piotrek\Pulpitping -l 1472 -f 127.0.0.1 Pinging 127.0.0.1 with 1472 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Since I was with two connection types (ADSL and dial-up), so this works: C:\WINDOWS\Profiles\Piotrek\Pulpitping -l 248 -f 127.0.0.1 Pinging 127.0.0.1 with 248 bytes of data: Reply from 127.0.0.1: bytes=248 time=1ms TTL=128 Reply from 127.0.0.1: bytes=248 time10ms TTL=128 Reply from 127.0.0.1: bytes=248 time=1ms TTL=128 Reply from 127.0.0.1: bytes=248 time10ms TTL=128 -l 1472 works for WAN machines (ie. .wp.pl), but not localhost nor LAN. So I deleted dialup connection - nothing changed. Then I've played with MaxMTU and such stuff - still nothing. Is this normal, or I'm out of luck (Win95+Winsock2)? This is offtopic, but maybe someone knows what's going on... -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Kliknij po wiecej! http://link.interia.pl/f18ed -- 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] Feature: single WindowHandle/thread
Hello! FP I have a development version for TWSocket which share the same window handle FP for as many TWSocket as you like (for one as now to any large value which FP fit your needs). Initially, I planned to make it available as a next majour FP release but I had no time to really finalize it yet. This would be nice :-) I heard you talking about this one year before and I was wondering when you planned to implement it officially. That's a huge change, and needs careful implementing. I believe that Francois wants the code to be working correctly in both single and multi threaded programs - and while it's easy in single threaded code, it isn't in multithreaded. Additionally TWSocket is async, that complicates things even more... So this long implementation time is pretty normal, at least I think so. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Zobacz finalistki Miss World!!! http://link.interia.pl/f18e8 -- 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] HTTP compression
Hello! released, effectively alpha testing. Unfortunately such alpha testing does not seem to be done by all ICS developers, so things get broken. Of the two pending beta components, I found MimeDec to cause one of my applications to no longer decode the last attachment part of email, and As I told before, it is not possible to leave it backward-compatible since original TMimeDec marks end of part at any boundary - it sees ending and starting boundary as one thing - resulting in phantom (empty) parts and nested parts corruption. But since all of you are more interested in leaving your software working improperly, I've dropped further TMimeDec development. My last patches are in the TMimeDec beta available (AFAIR) on Overbyte website - if anyone wants them, feel free to use them. Thanks. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- INTERIA.PL | Kliknij po wiecej http://link.interia.pl/f18c1 -- 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] transmission stress test
Hello! Have a look at TTWSChatForm.CliWSocketDataAvailable in TWSChat1.pas source file. There is a RcvBuf which is a stically allocated array of char (you can make it dynamically allocated) where data is received and the end of what has already been received. RcvLen variable keep track of how many bytes have been received so far. In that sample we know to have received all data (and maybe more) when we find a #10 in the data. This character mark the end of message (or end of line if you prefer). Then data is processed. What is after #10 is moved in front of buffer and RcvLen is adjusted accordingly. Yes, and you used similiar idea in TPop3Cli. Although it's simple to code, it's far from being optimal when you're about to receive short (40-80 chars) lines into medium/large sized buffer (say, 8kB) from relatively fast source - let's say we've received 8118 bytes, and let's assume that there's 99 lines, each consisting of 80 chars and 2-byte line end marker (cr/lf) -we of course don't know line lengths and amount of lines beforehand. Now let's fetch it. How does it work: - find cr/lf, traverse 81 bytes, stop at 81 - copy that 80 bytes to parser's buffer (or something like that) - move 8036 bytes of buffer, counting from 83 byte, back to the front - find cr/lf, traverse 81 bytes, stop at 81 - copy that 80 bytes to parser's buffer (or something like that) - move 7954 bytes of buffer, counting from 83 byte, back to the front [...] - find cr/lf, traverse 81 bytes, stop at 81 - copy that 80 bytes to parser's buffer (or something like that) - move 82 bytes of buffer, counting from 83 byte, back to the front - find cr/lf, traverse 81 bytes, stop at 81 - copy that 80 bytes to parser's buffer (or something like that) - note that we've hit buffer boundary, so exit. If we'll count well how many bytes were actually moved, we see that this solution is FAR from being optimal (for those who don't want/can't count it: we'll move 405702 bytes, or 396 kBytes). That superfluous memory moving is not the only bottleneck - here we have constant cache invalidation and cache misses, so if you change algorithm to better one (similiar to one below), you may get enormous speedups. That's the point of code I've sent you recently (btw: discard that if FBlockme=... line, I just forgot to delete it). And the algorithm is pretty simple, but more difficult to code: - set buffer cursor's current position as starting position - find cr/lf - if cursor hit buffer boundary (and cr/lf were not found), move everything from starting position to the end of buffer into the front of buffer, remember how many bytes were moved (as we want to receive new data after old, and we don't want old data to be deleted), and exit - otherwise, if cr/lf was found, copy data from starting position to byte before cr/lf to parser's buffer, and move cursor past cr/lf. This algorithm, in ours test case, has moved 7920 bytes (almost 8kB) bytes, cache wasn't dirtied, and if parser code was simple (like a call to TBufferedFileStream.Write), then buffer receiving could be done with speed at least near to optimal. And definitely it is NOT TRUE that it makes difference on just low-end cpu's. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- INTERIA.PL | Kliknij po wiecej http://link.interia.pl/f18c1 -- 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] Open to Suggestions
Hello! I have a COBOL DLL written that works and communicates well with the COBOL data. I would like to use the HTTPSERVER and call this DLL repeated times for various connections. Because of the SLOWNESS of this DLL and the overhead of having to initialize it each time, I really hate doing it in the BASE code of the HTTPSERVER. Hey, one moment - you load the dll, init it, call some code stored in it, deinit, and unload on each connection? -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Sa niesamowite, zobaczysz... ;-) link http://link.interia.pl/f18b9 -- 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] [TMimeDec] Beta version to test
Hello! However, I have a question. Decoding attachments seems to take a long time. Decoding a base64-encoded attachment of 10 MB takes 17 sec. On which machine? (cpu, mainboard, amount of free RAM, operating system...) If it's new/rather new machine, such result is far below expectations - I get 20 sec on old P120 with 32MB RAM and Win95. Is there a way to make the decoding work faster? I have about the same testresult on the beta and the older version of MimeDec. There's many ways to make it faster. First, do not use TMemoryStream as decoded attachment storage *unless* you set it's size so TMemoryStream won't need to reallocate his memory. Second, you should use larger input buffer (not that 4kbyte one), or change decoding logic so you could use memory- mapped file. Third, do not use OnPartLine to store data - set DestStream and leave OnPartLine unassigned (you'll save one jump into and out of the handler, possibly dirtying less processor's L1/L2 cache). Fourth, use TMemoryStream (or some kind of TBufferedWriteStream) as decoded data storage (but remember about the first note above). Fifth - discard these fancy progressbars (and progressbar updating code) ;) -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Sa niesamowite, zobaczysz... ;-) link http://link.interia.pl/f18b9 -- 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] abnormal winsock behaviour by firewall
Hello! Hello, Just information because I think this is interesting to know: Normally when I want to know if there is a server on a machine I try to connect on the port where it should listen and check Error argument in OnSessionConnected. If you do this on a machine where Norton antivirus is running, and you try to connect on port 'smtp' and there is _no_ server and 'mail checking' is checked in the antivirus thing then OnSessionConnected will fire without error and a while later OnsessionClose will fire with a 10053. There were other cases of abnormal behavior - AFAIR one of Outpost versions were breaking connection (without informing client about this) when one of data lines in POP3 connection exceeded 1024 bytes. Mail apps without any internal timeouts and manual connection breaking capabilities were mostly affected by this. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- O kobietach, dla kobiet... http://link.interia.pl/f18b4 -- 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] [TMimeDec] Beta version to test
Hello! And since you're too lazy to do a such simple thing, It's unfortunate your messages are so badly composed, full of capital letters which makes them hard to read, So what? My english isn't perfect, that's true. and essentially very irritating. More irritating is trying to convince me that buggy code is ok. And most irritating thing is having to remember that there's a bug in some code and you have to write special code to overcome it. I'll spend my time doing useful things, like enhancing ICS components properly, for the benefit of other. Yeah - properly, you mean, leaving old bugs as-is, just because this would cause component to behave differently? In case of problems, refer to TMimeDec (beta) sources I've really got better things to do than debug other people's source files. You've had to debug YOUR (TMimeDecEx) sources. Much easier to keep using a MineDec that works. It works - just for you. or RFC 2046. And reading an old document is hardly going to help make a Delphi program backward compatible. Got newer one? I don't think so, since there's no newer MIME specs. Just downloaded current rfc-index.txt (from http://www.rfc-editor.org), and... #v+ RFC INDEX - (CREATED ON: 09/07/2005.) This file contains citations for all RFCs in numeric order. [..] 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein. November 1996. (Format: TXT=105854 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2646, RFC3798) (Status: DRAFT STANDARD) [..] 2646 The Text/Plain Format Parameter. R. Gellens, Ed.. August 1999. (Format: TXT=29175 bytes) (Obsoleted by RFC3676) (Updates RFC2046) (Status: PROPOSED STANDARD) [..] 3798 Message Disposition Notification. T. Hansen, Ed., G. Vaudreuil, Ed.. May 2004. (Format: TXT=64049 bytes) (Obsoletes RFC2298) (Updates RFC3461, RFC2046) (Status: DRAFT STANDARD) #v- Certainly, reading RFC 2046 won't make Delphi program backward compatible, but at least may enlighten Delphi programmer. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Seks, zdrowie, uroda, praca... http://link.interia.pl/f18b3 -- 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] [TMimeDec] Beta version to test
Hello! And what was the cause? In TMimeDecEx you set destination stream after the part was decoded. You lose your data, because you don't save it: Hope this helps... :) Not really, you say there's bug in TMimeDecEx, but you don't say what you changed to get your 'result'. No response to my comments. This means either: 1 - the TMimeDec beta is buggy and should not be released. 2 - the TMimeDec beta is not backward compatible with existing applications, and should not be released. ROTFL You work for Microsoft, or what? The old and nasty bug is found and fixed, but we shouldn't release any patches for it, because our product won't be backward compatible and customers would stop writing to us noting the error. You didn't understood my previous message - I wrote how TMimeDec worked and how it works now - yes, it's not backward compatible - it cannot be backward compatible - but since current TMimeDec version is better (read: easier to use) - moving our asses and fixing ours code so IT WON'T RELY ON BUG ANYMORE should not be that hard. Remember that I've had to do the same with HCM - if you didn't relied on that bug too many times, it shouldn't be big pain anyway (in my case it just took 5 minutes to fix, by the way I've removed some tricky code that fixed that bug on higher level). And you wasted almost a week waiting for piece of information that you could find out on your own. You just had to sit down for 15 minutes, read completely my message, re-read your sources, and make it disable part saving/DestStream setting in OnPartEnd since it is called ON PART END, not ON ANY BOUNDARY DETECTION (like it was until new TMimeDec beta), so when you're past first plain text part, you're past first plain text part, not earlier. And since you're too lazy to do a such simple thing, I decided to not respond. I can be lazy too. If I've made a simple error in TMimeDecEx, please tell me what it is, I've pointed it out already. Twice. and why it's able to correctly decode all content parts except the last, which is always empty, using the same events, yet works fine with the old TMineDec. Everything is in my previous message (message-id: [EMAIL PROTECTED]). Please read it carefully. In case of problems, refer to TMimeDec (beta) sources or RFC 2046. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Startuj z INTERIA.PL! http://link.interia.pl/f186c -- 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] FTPClient speeds
Hello! I wrote a write-buffering stream. Anyone interested? Adding read and seek support and extending it so it can write to other streams shouldn't be difficult. snip I thought windows buffered writes anyway? Is this so you can have a larger buffer or something completely different? Indeed, Windows buffers writes, so disk heads don't go over FAT and file too frequently (without buffering, every write consists of writing data to the disk in both file data sectors, and FAT sectors - three writes, one byte each, will cause five or six head seeks, with buffering, there'll be only one actual write to file and one FAT update). But parameter checking and windows' internal buffering code is slower than buffering on application side. That is - having your app to write in greater chunks speeds things up CONSIDERABLY. Why won't you check it? :) -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- Startuj z INTERIA.PL! http://link.interia.pl/f186c -- 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
