Angus Robertson - Magenta Systems Ltd wrote:
>> FTP also still not supporting IPv6
>
> FTP needs the EPRT and EPSV commands to support IP6:
>
> http://tools.ietf.org/html/draft-ietf-ftpext-ftp-over-ipv6-01
>
> from 1998, but IP6 has been slow arriving. The latest version of
> Serv-U supports th
We use TStringList quicksort/binary search routine I wrote for
caching--works so well that I can recommend.
With many entries all TList-derrived classes are dog-slow
compared with binary search trees for this purpose!
Confirmed. I recently had a project with such issue. The result where
extre
Fastream Technologies wrote:
>>> We use TStringList quicksort/binary search routine I wrote for
>>> caching--works so well that I can recommend.
>>
>> With many entries all TList-derrived classes are dog-slow
>> compared with binary search trees for this purpose!
>
> We are using Sorted=true; wh
On Thu, Jun 3, 2010 at 3:43 PM, Arno Garrels wrote:
>
> Fastream Technologies wrote:
> > Hello,
> >
> > We use TStringList quicksort/binary search routine I wrote for
> > caching--works so well that I can recommend.
>
> With many entries all TList-derrived classes are dog-slow
> compared with bina
Fastream Technologies wrote:
> Hello,
>
> We use TStringList quicksort/binary search routine I wrote for
> caching--works so well that I can recommend.
With many entries all TList-derrived classes are dog-slow
compared with binary search trees for this purpose!
>
> Also, has anybody tested the
Hello,
We use TStringList quicksort/binary search routine I wrote for
caching--works so well that I can recommend.
Also, has anybody tested the IPv6 with listening/server components?
Best Regards,
SZ
On Wed, Jun 2, 2010 at 10:04 PM, Francois PIETTE
wrote:
> How fast/slow this implementation w
How fast/slow this implementation works with thousands of
concurrent requests is of course untested. One DNS lookup may
take one or even multiple seconds in the worst case.
Shouldn't TWSocket have his own internal cache for DNS lookup ? Or maybe
instead of more complex TWSocket, maybe a compone
Fastream Technologies wrote:
> On Wed, Jun 2, 2010 at 7:33 PM, Arno Garrels
> wrote:
>
>> Arno Garrels wrote:
>>> Fastream Technologies wrote:
Hello,
Has the IPv6 async DNS resolving issue been resolved? How
many socket/threads?
>>>
>>> There is a (hopefully) thread-safe ne
On Wed, Jun 2, 2010 at 7:33 PM, Arno Garrels wrote:
> Arno Garrels wrote:
> > Fastream Technologies wrote:
> >> Hello,
> >>
> >> Has the IPv6 async DNS resolving issue been resolved? How
> >> many socket/threads?
> >
> > There is a (hopefully) thread-safe new class which provides
> > async lookup
Hello,
On Wed, Jun 2, 2010 at 7:33 PM, Arno Garrels wrote:
> Arno Garrels wrote:
> > Fastream Technologies wrote:
> >> Hello,
> >>
> >> Has the IPv6 async DNS resolving issue been resolved? How
> >> many socket/threads?
> >
> > There is a (hopefully) thread-safe new class which provides
> > asyn
Arno Garrels wrote:
> Fastream Technologies wrote:
>> Hello,
>>
>> Has the IPv6 async DNS resolving issue been resolved? How
>> many socket/threads?
>
> There is a (hopefully) thread-safe new class which provides
> async lookups. One global object of this class is allocated in
> unit initializati
Fastream Technologies wrote:
> Hello,
>
> Has the IPv6 async DNS resolving issue been resolved? How
> many socket/threads?
There is a (hopefully) thread-safe new class which provides
async lookups. One global object of this class is allocated in
unit initialization with the maximum number of thr
Hello,
Has the IPv6 async DNS resolving issue been resolved? How
many socket/threads?
Best Regards,
SZ
On Sun, May 30, 2010 at 6:26 PM, Arno Garrels wrote:
> Angus Robertson - Magenta Systems Ltd wrote:
> >> FTP also still not supporting IPv6
> >
> > FTP needs the EPRT and EPSV commands to su
Angus Robertson - Magenta Systems Ltd wrote:
>> FTP also still not supporting IPv6
>
> FTP needs the EPRT and EPSV commands to support IP6:
>
> http://tools.ietf.org/html/draft-ietf-ftpext-ftp-over-ipv6-01
>
> from 1998, but IP6 has been slow arriving. The latest version of
> Serv-U supports th
Francois PIETTE wrote:
>>> Turned out to be more work than initially planned.
>>> Maybe we should create a svn branch for it?
>>
>> What makes you think another branch would be useful ?
>
>> Better testing before it's finally commited to the main
>> branch.
>
> OK, go on.
Opened, the URL is
"s
> FTP also still not supporting IPv6
FTP needs the EPRT and EPSV commands to support IP6:
http://tools.ietf.org/html/draft-ietf-ftpext-ftp-over-ipv6-01
from 1998, but IP6 has been slow arriving. The latest version of Serv-U
supports these IP6 commands.
I did check with my ISP about IP6, the
Turned out to be more work than initially planned.
Maybe we should create a svn branch for it?
What makes you think another branch would be useful ?
Better testing before it's finally commited to the main
branch.
OK, go on.
--
francois.pie...@overbyte.be
The author of the freeware multi-t
Francois PIETTE wrote:
>> Turned out to be more work than initially planned.
>> Maybe we should create a svn branch for it?
>
> What makes you think another branch would be useful ?
Better testing before it's finally commited to the main
branch. I did some general cleanup including removal of
al
Turned out to be more work than initially planned.
Maybe we should create a svn branch for it?
What makes you think another branch would be useful ?
--
francois.pie...@overbyte.be
http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://l
Hi,
Yes I know the experimental OpenSSL card support has been there for some
time but for production we need a tested solution and I sent a message to
the list for sponsoring this--cannot get one here in Turkey for affordable
price and need somebody to rent/buy one and do the test so that we can
a
Fastream Technologies wrote:
> Ok, no problem. BTW, we are very interested in OpenSSL accelerators
It's already included as an experimental feature since a while,
however there was zero feedback from developers owning accelerator
hardware yet. All you need to test is a system with an accelerator
On Sat, May 29, 2010 at 5:21 PM, Arno Garrels wrote:
> Fastream Technologies wrote:
> > I said so because I had faced a WinXP/Vista x64 issue (BLUE SCREEN)
> > which MS fixed in Win7. I thought it might be something similar. BTW,
> > did you see the message I sent to you privately? It's been a wh
Fastream Technologies wrote:
> I said so because I had faced a WinXP/Vista x64 issue (BLUE SCREEN)
> which MS fixed in Win7. I thought it might be something similar. BTW,
> did you see the message I sent to you privately? It's been a while
> since I heard back from you to my replies and I am beginn
I said so because I had faced a WinXP/Vista x64 issue (BLUE SCREEN) which MS
fixed in Win7. I thought it might be something similar. BTW, did you see the
message I sent to you privately? It's been a while since I heard back from
you to my replies and I am beginning to think that it could be a spam
Fastream Technologies wrote:
> Maybe it is another 64-bit Windows/debugger API issue? I am using
> Win7 Pro x64 and had been using 64-bit XP and Vista for 4 years...
I do not think it's related to 64-Bit Windows. I tested and got the AV
with Delphi 7 and Delphi 2010 on XP-Pro SP3 (fully patched),
Currently I made one breaking change that IMO cannot be prevented without
tons of workaround code.
That is type change of TCustomWSocket public field/property "sin" from
TSockAddrIn to TSockAddrIn6. TSockAddrIn6 can be passed to all old
functions by typ casting it to TSockAddrIn and passing the si
Maybe it is another 64-bit Windows/debugger API issue? I am using Win7 Pro
x64 and had been using 64-bit XP and Vista for 4 years...
SZ
On Sat, May 29, 2010 at 1:55 PM, Francois PIETTE
wrote:
> I made a very simple test case which triggers the AV on different
>> hardware and Windows versions in
I made a very simple test case which triggers the AV on different
hardware and Windows versions in both D7 and D2010 here.
However some German testers were not able to reproduce the issue,
very strange.
I cannot reproduce the issue.
I'm using Vista Ultimate 32 bit with all services packs install
Francois PIETTE wrote:
>> When new property SocketFamily is set to "sfAny" method
>> DnsLookup may now return a list containing both IPv4 and IPv6
>> strings. Looks like Windows always returns IPv6 first.
>> The top item is also copied to string FDnsResult.
>> Should I change this order?
>
> An id
RTT wrote:
> Is happening here too, but only if I continue with the step over
> debugging (F8) after the 4 thread are created. Never happened while
> they are created. No idea if that's what you want to say with "repeat
> pressing F8 until the AV is raised."
> The debugger will keep stepping the Wm
When new property SocketFamily is set to "sfAny" method
DnsLookup may now return a list containing both IPv4 and IPv6
strings. Looks like Windows always returns IPv6 first.
The top item is also copied to string FDnsResult.
Should I change this order?
An idea: Give the opportunity for the develop
Not sure if it is the same issue but with our proxy server code with many
threads, the debugger sometimes gives AV on Wndproc when step run too.
SZ
On Sat, May 29, 2010 at 11:38 AM, Arno Garrels wrote:
> Hi,
>
> When new property SocketFamily is set to "sfAny" method
> DnsLookup may now return
Is happening here too, but only if I continue with the step over
debugging (F8) after the 4 thread are created. Never happened while they
are created. No idea if that's what you want to say with "repeat
pressing F8 until the AV is raised."
The debugger will keep stepping the WmTest function, un
Hi,
When new property SocketFamily is set to "sfAny" method
DnsLookup may now return a list containing both IPv4 and IPv6
strings. Looks like Windows always returns IPv6 first.
The top item is also copied to string FDnsResult.
Should I change this order?
BTW.: I wrote some helper classes to emul
34 matches
Mail list logo
