LNET versus INDY versus Synapse

[Dibo]

So I suppose I must call HTTPClient.CallAction inside some loop like in lHTTP console demo? Sounds good but still doesn't work :/

Edit: Ok, I looked again to console demo and it uses TLHTTPClient instead of LCL TLHTTPClientComponent. Now it works . Thanks for tip marcov.

[Almindor]

Dibo: can I close the bug then? I still haven't got around to getting in windows (... ), if it was a LCL .dll/lib thing I think lNet/visual can't work like that (and anything else bound to LCL imo).

[Dibo]

No problem, but had you read my last comment in this issue? I think the reason is that AppHandle is 0 in DLL but don't know why . I'm looking now for some eventer which work in DLL (AddEventHandler(HttpClient.Iterator.Handle...) doesn't work :/ ) . I think I just use loop in thread to CallAction.

[Almindor]

Yes, but keep in mind that if you run .CallAction in a thread, ALL your On<anything> events assigned to lNet objects will also be called from within this thread!

Make sure to synchronize data operations you do with the data in the events.

[xenblaise]

i choose what ever lazarus got the default package for networking task

[jl]

My order is:

1. LNet - if I can I always use this sockets (if I need TCP/IP it always win). Very fast and lightweight (good choice for mobile platform). Really cross platform (Windows, Windows mobile, Linux, MacOS, etc) Have no-blocking mode, but...

Hi Dibo, I'm now considering LNET.  Care to elaborate on the "but..."?     

[xenblaise]

 

[avra]

I have made a custom OPC server that was getting it's data from polling some TCP server in 2008 with Delphi. It was an application that should work for months on Win2K3 server without interruption. Originally I have used AsyncPro TCP client, but after about every 2 weeks server crashed. I traced the problem to AsyncPro memory leaks. Then I have rewritten everything to Indy, and it was better but not good enough. Server crashed about every 2 months. Then I changed to Synapse. No problem ever since. To be fair I must repeat that it was 2008, and things may have changed since then.

[JD]

I have made a custom OPC server that was getting it's data from polling some TCP server in 2008 with Delphi. It was an application that should work for months on Win2K3 server without interruption. Originally I have used AsyncPro TCP client, but after about every 2 weeks server crashed. I traced the problem to AsyncPro memory leaks. Then I have rewritten everything to Indy, and it was better but not good enough. Server crashed about every 2 months. Then I changed to Synapse. No problem ever since. To be fair I must repeat that it was 2008, and things may have changed since then.

If you can spare the time & the resources, try a more recent version of Indy.
http://lazarus.freepascal.org/index.php/topic,12772.0.html
I'm interested to know how it performs in your application

[Graeme]

I always use Indy.

What version of Indy do you use?

[JD]

I always use Indy.

What version of Indy do you use?

Use a recent version of Indy
http://lazarus.freepascal.org/index.php/topic,12772.0.html
That way, if you have problems, the Indy team will be better positioned to help you.

The official version for Lazarus is way too old. Download a newer version of Indy from http://indy.fulgan.com/ZIP/

[avra]

If you can spare the time & the resources, try a more recent version of Indy.
http://lazarus.freepascal.org/index.php/topic,12772.0.html
I'm interested to know how it performs in your application

That application is a backbone in an important industrial process and I can not afford to get back to old version with less features and let it run for few months just to retest current Indy version. Sorry.

[JD]

If you can spare the time & the resources, try a more recent version of Indy.
http://lazarus.freepascal.org/index.php/topic,12772.0.html
I'm interested to know how it performs in your application

That application is a backbone in an important industrial process and I can not afford to get back to old version with less features and let it run for few months just to retest current Indy version. Sorry.

It's OK, I understand the limitation. Besides as they say "if it ain't broke, don't fix it". 

[jl]

If you can spare the time & the resources, try a more recent version of Indy.
http://lazarus.freepascal.org/index.php/topic,12772.0.html
I'm interested to know how it performs in your application

That application is a backbone in an important industrial process and I can not afford to get back to old version with less features and let it run for few months just to retest current Indy version. Sorry.

It's OK, I understand the limitation. Besides as they say "if it ain't broke, don't fix it".  

It might work for windows, but Indy 10.5 doesn't work for Linux due to iconv failure, you can find more details here - http://tech.dir.groups.yahoo.com/group/Indy-Dev-Public/messages.

I've decided to revert to Indy 10.2.0.3, which is relatively stable.