LNET versus INDY versus Synapse lazarus / 38-Networking and Web Programming ---------------------------------------------------------------------- jl · 2010-09-17 02:57 Hi, i've been trying to search for a stable TCP component for lazarus that works on both Ubuntu and Windows platform.  On Windows, Indy and TWSockets are popular.  On Linux, it seems that Indy has a lot of bugs. My coder suggested using LNET for client component, but i took a look at LNET, work seems to have stopped in 2008?  Another issue is the lack of PING, which is part of my requirement. Hope to hear the opinion of you guys.  Thanks. ---------------------------------------------------------------------- j4ckr1pp3r · 2010-09-17 06:11 my opinion: try them all if you feel comfortable with vcl then try lnet http://lnet.wordpress.com/news/ for me, i feel comfortable with synapse ---------------------------------------------------------------------- theo · 2010-09-17 07:50 Synapse has TPingSend http://synapse.ararat.cz/doc/help/pingsend.TPINGSend.html ---------------------------------------------------------------------- jarto · 2010-09-17 14:06 Synapse is a very good choice when you need to be compatible with both Linux and Windows. You can use the same components and same code with both platforms and also with Delphi/Kylix. There's one area where Indy is better: https server. The https- implementation in Synapse is not stable on Linux. I've reported the problem but not solution has been found so far: http://www.mail-archive.com/synalist- public@lists.sourceforge.net/msg03136.html ---------------------------------------------------------------------- garlar27 · 2010-09-17 18:48 Using Ping on linux needs root permissions. So you will have to loggin as root or give root priviledges to the application. I think there might be other ways to do it. ---------------------------------------------------------------------- OpenLieroXor · 2010-09-17 19:28 For me Synapse is the best networking library - stable, powerful and cross-platform. About pinging, I think it's not good to do ping using ICMP sockets directly, because you need administrative (root) privileges both under Linux and Windows (however, under Windows usually you get it by default). The better solution is to use 'ping' command in the command line, because it can be performed by normal users. ---------------------------------------------------------------------- Dibo · 2010-09-17 23:23 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... 2. ... HTTPClient is very restricted, so I use Synapse socket (i have a total control on every part like headers, request body, response body, redirection, SSL etc). Have blocking mode so I mostly must use threads. Support only for windows and linux (and use winsock on linux?). On windows mobile (tested year ago) I had add some compiler defines manually. 3. If all else fails I use Indy - very heavy but have everything, and if something is not working on LNet/Synapse sockets, is always work on Indy ---------------------------------------------------------------------- jixian.yang · 2010-09-18 08:32 Quote from: jarto on September 17, 2010, 04:06:52 pm There's one area where Indy is better: https server. The https- implementation in Synapse is not stable on Linux. I've reported the problem but not solution has been found so far: http://www.mail-archive.com/synalist- public@lists.sourceforge.net/msg03136.html Synapse seems stable on linux. Please cut "Sock.SSL.CertCAFile := ExtractFilePath(ParamStr(0)) + 's_cabundle.pem';   Sock.SSL.CertificateFile := ExtractFilePath(ParamStr(0)) + 's_cacert.pem';   Sock.SSL.PrivateKeyFile := ExtractFilePath(ParamStr(0)) + 's_cakey.pem';   Sock.SSL.KeyPassword := 's_cakey';   Sock.SSL.verifyCert := True; "and paste it into "procedure TTCPHttpDaemon.Execute;   with sock do " and try again. ---------------------------------------------------------------------- ahmetnurideniz · 2010-09-18 12:16 i use lnet for telnet cominicatin. i test indy telnet but it has error on my system. but may be it is my own problem. Lnet is work stable and very easy for me. Note : i am new  network programer ---------------------------------------------------------------------- jarto · 2010-09-18 18:29 Quote from: jixian.yang on September 18, 2010, 10:32:33 am Synapse seems stable on linux. Please cut "Sock.SSL.CertCAFile := ExtractFilePath(ParamStr(0)) + 's_cabundle.pem';   Sock.SSL.CertificateFile := ExtractFilePath(ParamStr(0)) + 's_cacert.pem';   Sock.SSL.PrivateKeyFile := ExtractFilePath(ParamStr(0)) + 's_cakey.pem';   Sock.SSL.KeyPassword := 's_cakey';   Sock.SSL.verifyCert := True; "and paste it into "procedure TTCPHttpDaemon.Execute;   with sock do " and try again. Yes, that's the way you add HTTPS support to Synapse. It's rock solid on Windows, but crashes on Linux under heavy traffic. I've reproduced the problem with both FPC and Kylix and on several Linux distributions. ---------------------------------------------------------------------- jl · 2010-09-21 16:17 Quote from: jarto on September 18, 2010, 08:29:26 pmQuote from: jixian.yang on September 18, 2010, 10:32:33 am Synapse seems stable on linux. Please cut "Sock.SSL.CertCAFile := ExtractFilePath(ParamStr(0)) + 's_cabundle.pem';   Sock.SSL.CertificateFile := ExtractFilePath(ParamStr(0)) + 's_cacert.pem';   Sock.SSL.PrivateKeyFile := ExtractFilePath(ParamStr(0)) + 's_cakey.pem';   Sock.SSL.KeyPassword := 's_cakey';   Sock.SSL.verifyCert := True; "and paste it into "procedure TTCPHttpDaemon.Execute;   with sock do " and try again. Yes, that's the way you add HTTPS support to Synapse. It's rock solid on Windows, but crashes on Linux under heavy traffic. I've reproduced the problem with both FPC and Kylix and on several Linux distributions. How heavy is heavy?  Like 1 query per second?  Or dozens of queries per second? Does it generate heap trace on Linux?  I seem to be getting that with Synapse on Ubuntu. ---------------------------------------------------------------------- jl · 2010-09-21 16:20 Quote from: Dibo on September 18, 2010, 01:23:40 am2. ... HTTPClient is very restricted, so I use Synapse socket (i have a total control on every part like headers, request body, response body, redirection, SSL etc). Have blocking mode so I mostly must use threads. Support only for windows and linux (and use winsock on linux?). On windows mobile (tested year ago) I had add some compiler defines manually. Thanks for sharing.  I was told Synapse doesn't work well for multi- threading code. ---------------------------------------------------------------------- jarto · 2010-09-21 17:19 Quote from: touchring on September 21, 2010, 06:17:01 pm How heavy is heavy?  Like 1 query per second?  Or dozens of queries per second? Does it generate heap trace on Linux?  I seem to be getting that with Synapse on Ubuntu. Heavy means dozens or hundreds of queries per second. Check the whole thread at the link I posted earlier for details. ---------------------------------------------------------------------- jarto · 2010-09-21 17:24 Quote from: touchring on September 21, 2010, 06:20:04 pmThanks for sharing.  I was told Synapse doesn't work well for multi-threading code. Synapse's client code works like charm with multi-threaded code on both Windows and Linux. The only problem is if you try to create a https server with it on Linux. There's something wrong with how Synapse calls OpenSSL there. ---------------------------------------------------------------------- garlar27 · 2010-09-21 18:43 I use Synapse for threaded serial communication on Linux and Windows without problems. lNet and Synapse are great components. I think it's hard to choose one. The main difference I can see is:    lNet: higher level, event driven.    Synapse: lower level (you can deal with the nuts and bolts). I don't know if someone have done serious tests to compare those components. ---------------------------------------------------------------------- BeniBela · 2010-09-22 12:29 Quote from: jarto on September 21, 2010, 07:24:12 pmSynapse's client code works like charm with multi-threaded code on both Windows and Linux. How do you use it? On linux it very often fails (returning an empty stringlist) for me, even if I just call HttpGetText in multiple-threads. [edit:]I just tracked it down a little bit, and it seems what fails is the dns query.  Does it also works with a router for you ? ---------------------------------------------------------------------- jl · 2010-09-22 16:56 Quote from: garlar27 on September 21, 2010, 08:43:42 pmI use Synapse for threaded serial communication on Linux and Windows without problems. lNet and Synapse are great components. I think it's hard to choose one. The main difference I can see is:    lNet: higher level, event driven.    Synapse: lower level (you can deal with the nuts and bolts). I don't know if someone have done serious tests to compare those components. Thanks, do you mean Synaser? I am getting the following errors when I try to install my threaded Indy app with heaptrace on.  I'm using indy 10.2.0.3, FPC 2.2.4, Lazarus 0.9.28.2, Lazdaemon. Any thoughts?  Heap dump by heaptrc unit 343 memory blocks allocated : 19803/20888 340 memory blocks freed     : 19735/20808 3 unfreed memory blocks : 68 True heap size : 262144 (160 used in System startup) True free heap : 261712 Should be : 261736 Call trace for block $0006D950 size 28   $00408512   $004673AD  TIDTHREADSAFE__CREATE,  line 217 of d:/ oy/SMSDispatcher/LANProwler/indy-10.2.0.3/fpc/IdThreadSafe.pas   $0045B22F  IDTHREAD_init,  line 601 of d:/loy/SMSD spatcher/LANProwler/indy-10.2.0.3/fpc/IdThread.pas   $00409FE4   $0040DF70   $00409FE4   $0040DF70 Call trace for block $0007ECF8 size 12   $00408512   $0045B22F  IDTHREAD_init,  line 601 of d:/loy/SMSD spatcher/LANProwler/indy-10.2.0.3/fpc/IdThread.pas   $00409FE4   $0040DF70 Call trace for block $0006D9B0 size 28   $00408512   $00441E6C  IDSTACK_init,  line 870 of d:/loy/SMSDi patcher/LANProwler/indy-10.2.0.3/fpc/IdStack.pas   $00409FE4   $0040DF70   $004353D8  LCLPROC_init,  line 4466 of lclproc.pas   $00409FE4   $0040DF70 ---------------------------------------------------------------------- jl · 2010-09-23 01:23 Remy Lebeau replied to me on the Indy newsgroup. Quote> I am getting the following errors when I try to install my threaded > Indy app with heaptrace on. Those are the standard (ie, intentional) Indy memory leaks.  Look at the comments in the finalization sections of IdThread.pas and IdStack.pas.  In Delphi versions that use FastMM for the memory manager, those leaks are registered with FastMM so they are not reported in leak reports.  I don't know if FPC has a similar option available. You can enable the FREE_ON_FINAL directive in IdCompilerDefines.inc to remove the leaks, though. > I'm using indy 10.2.0.3 That is a VERY old version.  The current version is 10.5.8. > FPC 2.2.4, Lazarus 0.9.28.2, Lazdaemon. There is some debate amongst the Indy team right now whether the current version works correctly in Lazarus.  Would you be able to test that for us? -- Remy Lebeau (TeamB) ---------------------------------------------------------------------- bobo · 2010-09-29 23:10 Funny that they ask You to test if the current version is working when they are the developers. I am sure people would be willing to test it though if they could. I've checked out their SVN source code (about 260MB). From some website notes they had, the latest 10.5.8 is under the Tiburon branch there (not trunk), which does have some Makefile.fpc files in some sub-directories (with still containing a version number 10.2.0.1). Under /Lib/FCL/IdVers.inc it says 10.5.6 ... However, zero readme-s or instruction on how to compile with FPC. Under /Lib/fpcnotes/ there is a README file saying to go to directory "fpc" and do a make. The only problem is, that there is no such directory (If memory servers, there was, in a special made indy version 10.2.0.3 made back in 2007 that can still be used with current FPC/Lazarus). Looks like this directory was just copied over from that one. So... it would be very hard to test whether it works if we can not even try to compile it... Some more help is needed from them. ---------------------------------------------------------------------- jixian.yang · 2010-10-19 23:22 Synapse https server demo works fine now when the SVN version of Synapse has been updated. The Synapse https seems stable on Linux now. ---------------------------------------------------------------------- marcov · 2010-10-20 05:31 I always use Indy. The "heavy" label it gets strapped to it is IMHO more emotional than technical, and not worth keeping knowledge about multiple such sets around. So I pick the most feature complete. ---------------------------------------------------------------------- jixian.yang · 2010-10-26 10:47 In Synapse fixed version, it uses BaseUnix instead of Libc in ssl_openssl_lib. ---------------------------------------------------------------------- vfclists · 2011-01-26 09:49 Which version do you currently use? Is it still the 10.2.0.3 version? Quote from: marcov on October 20, 2010, 07:31:18 amI always use Indy. The "heavy" label it gets strapped to it is IMHO more emotional than technical, and not worth keeping knowledge about multiple such sets around. So I pick the most feature complete. ---------------------------------------------------------------------- marcov · 2011-01-26 09:56 Quote from: vfclists on January 26, 2011, 10:49:59 amWhich version do you currently use? Is it still the 10.2.0.3 version? Quote from: marcov on October 20, 2010, 07:31:18 amI always use Indy. The "heavy" label it gets strapped to it is IMHO more emotional than technical, and not worth keeping knowledge about multiple such sets around. So I pick the most feature complete. Afaik the old version works with designtime, and the new version only works (with some minimal fixes) runtime. But I mostly used it runtime. I haven't touched that project in half an year though. There is btw nothing wrong with Synapse, except the FUD about Indy spread by some of its followers. I have also used (and ported) ICS in the past, but it is fundamentally Windows specific. If you really need to exploit all possibilties from the windows stack, it can be an option though. I never used lnet. A few experiments failed, and there are too little components. Moreover it was *nix only most of the time, and I also need WIndows support. ---------------------------------------------------------------------- vfclists · 2011-01-26 10:08 Quote from: marcov on January 26, 2011, 10:56:13 amQuote from: vfclists on January 26, 2011, 10:49:59 amWhich version do you currently use? Is it still the 10.2.0.3 version? Quote from: marcov on October 20, 2010, 07:31:18 amI always use Indy. The "heavy" label it gets strapped to it is IMHO more emotional than technical, and not worth keeping knowledge about multiple such sets around. So I pick the most feature complete. Is it the current 10.5.x series you are using? Do you compile it right out of subversion? QuoteAfaik the old version works with designtime, and the new version only works (with some minimal fixes) runtime. But I mostly used it runtime. I haven't touched that project in half an year though. ---------------------------------------------------------------------- marcov · 2011-01-26 10:20 Quote from: vfclists on January 26, 2011, 11:08:46 am Is it the current 10.5.x series you are using? Do you compile it right out of subversion? IIRC the last time I tried was in June. That was just before the Tiberon branch was merged back to trunk. (one should afaik use trunk again now, tiberon branch is afiak no longer updated). I tried to get the designtime bits running, but never succeeded, and decided to wait for a fully 2.4.x based release of lazarus first. Afaik sb from the pgg (the ones that publish Blaise magazine) want to try too somewhere in fall, but I haven't heard from them again. ---------------------------------------------------------------------- Dibo · 2011-01-28 13:10 About lNet. It doesn't work in DLL. ---------------------------------------------------------------------- marcov · 2011-01-28 16:04 Quote from: Dibo on January 28, 2011, 02:10:00 pmAbout lNet. It doesn't work in DLL. In general, you need to know what you are doing inside DLL. It is not a LNet specific problem. ---------------------------------------------------------------------- Dibo · 2011-01-28 18:08 What do you mean? I posted bug today with this issue: http://bugs.freepascal.org/view.php?id=18625 Maybe unnecessarily? I just put TLHTTPClient on form and to this same things like in normal GUI application. What more can I do? For example, synapse works fine in DLL. Regards ---------------------------------------------------------------------- marcov · 2011-01-28 18:19 Quote from: Dibo on January 28, 2011, 07:08:14 pmWhat do you mean? I posted bug today with this issue: http://bugs.freepascal.org/view.php?id=18625 Maybe unnecessarily? I just put TLHTTPClient on form and to this same things like in normal GUI application. Currently, DLLs generated with FPC have a static RTL (and all other libs) integrated. That's the "know what you are doing" is coming in, you need to maintain two states of components and libraries (since you have two rtls, two lcls, two eventloops etc) QuoteWhat more can I do? For example, synapse works fine in DLL. Pure luck as far as I know. ---------------------------------------------------------------------- Dibo · 2011-01-28 19:03 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 · 2011-01-31 20:03 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 · 2011-01-31 20:13 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 · 2011-02-02 09:26 Yes, but keep in mind that if you run .CallAction in a thread, ALL your On 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 · 2011-02-12 16:11 i choose what ever lazarus got the default package for networking task ---------------------------------------------------------------------- jl · 2011-04-22 04:19 Quote from: Dibo on September 18, 2010, 01:23:40 amMy 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 · 2011-05-25 16:44 ---------------------------------------------------------------------- avra · 2011-05-26 09:39 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 · 2011-05-26 10:23 Quote from: avra on May 26, 2011, 11:39:33 amI 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 · 2011-05-26 18:36 Quote from: marcov on October 20, 2010, 07:31:18 amI always use Indy. What version of Indy do you use? ---------------------------------------------------------------------- JD · 2011-05-26 19:28 Quote from: Graeme on May 26, 2011, 08:36:15 pmQuote from: marcov on October 20, 2010, 07:31:18 amI 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 · 2011-05-27 08:14 QuoteIf 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 · 2011-05-27 09:34 Quote from: avra on May 27, 2011, 10:14:03 amQuoteIf 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 · 2011-06-05 17:49 Quote from: JD on May 27, 2011, 11:34:42 amQuote from: avra on May 27, 2011, 10:14:03 amQuoteIf 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.