1a. What is lNet?
lNet is a networking library made specificly for Free Pascal compiler and optionaly Lazarus. It consists of the base unit (lnet.pas) and additional protocol units such as FTP (lftp.pas) and Telnet (lTelnet.pas). lNet was made with simplicity and
portability in mind.
There are many high-quality networking frameworks out there and most of them outgrow lNet. However most other frameworks are non-portable (or only portable between Linux and Windows) while lNet works on most platforms and architectures supported by Free Pascal. Another consideration is simplicity (base library is
~1000 lines of code) and speed (no internal buffers).
It’s lNet with “L” as first letter. The choice of lowercase “l” was made for good looks nothing else. The “l” means lightweight.
lNet should run on most platforms supported by Free Pascal compiler which implement a semi-standard BSD TCP/IP stack. Currently tested platforms and architectures are: Windows (98+, requires winsock2), Linux x86, Linux PPC, FreeBSD, MacOSX – PPC, MacOSX x86, WinCE. All platforms 32 and 64 bit.
Yes you can. lNet is licensed under a modified LGPL license same as RTL of FPC or LCL of Lazarus libraries use. This means in short that you can static (smart) link lNet in your application and not provide sources with your program. It would be a nice thank-you if you mentioned it’s use in your application or donated some money if possible.
First you must have a subversion client program. For unix: get “svn” or “subversion” package or port depending on your “distro”.
For windows: get tortoise svn and install it.
Next you need to “checkout” the lNet source tree to a directory on your local computer.
For unix: svn co http://svn.freepascal.org/svn/fpcprojects/lnet/trunk lnet
For windows: right click in explorer on the place you want to “checkout” to and select SVN/Checkout. Fill the “host” with “http://svn.freepascal.org/svn/fpcprojects/lnet/trunk” You can subsequently update after this.
For unix: svn up lnet
For windows: right click the lNet dir, svn/svn update.
Short answer, no. Multithreading brings with it loads of problems on certain platforms and I don’t think it’s good to integrate right into the base lib. lNet can be easily used with threads if you specify a >0 TimeOut property. There are plans to introduce a “thread pooling” eventer in the future.
Depends on platforms and protocols. The base lNet library (lnet.pas) does not require LibC on most platforms (MacOSX/Darwin is the exception). It also depends on FPC since on some platforms the RTL uses LibC. Additional protocols might require LibC and other external libraries tho. Good example is the planned SSL
support protocol which will require OpenSSL and LibC (because of openSSL), but it will be made optional.
Yes. There’s even a Lazarus visual components package here. If you’re developing visual applications which need networking I strongly advise you to use the package instead of base lNet lib as it uses LCL integration for events and doesn’t require CallAction to function. (which is a great advantage)
Non-visual lNet (lnetbase) uses the most optimized polling mechanism depending on OS to find out wether something happens on a socket. This requires “hooking” into main event loop of your program. On the other hand it can be faster if done properly or you can easily integrate it into multi-threaded application with the Timeout property.
The visual lNet (see previous question) is designed for visual applications done with Lazarus. It integrates with LCL (and subsequently the widgetset) and uses it’s mechanisms (see here) to function. The advantage of this approach is that you don’t need to call CallAction anymore and thus it works “automagically”.
The CallAction method of all “Connections” is a method which “eventizes” the whole connection. It is valid only in non-visual lNet. Whenever you call this method, all sockets of given connection are checked for status updates (eg. if something can be received, if I can send…) and appropriate callbacks are fired. You need to call this method periodicly to assure functionality. You need to CallAction periodicly if you want to know if you can receive. (get)
The SNum or SocketNumber property is now obsolete. It was used in the past as the unique identificator of sockets most notably for use in TCP servers. The reasons why it was removed are numerous most notably design changes and performance. If you need to “remember” sockets somehow you should make a list of them (you get “aSocket” argument on each event). Make sure however to remove them from your list on Disconnect and Error events, otherwise you’ll get an AV.
You should use the Iterator property together with IterReset and IterNext methods. Iterator always points to the “active” socket. If you need to send something to all sockets you should first IterReset (so that it points to the server socket) and then do a while cycle like this:
while Connection.IterNext do Connection.Send(..., Connection.Iterator);
Ofcourse this is just basic example. Real code should also contain error check for connected status of sockets, sends (if I sent all data) etc. The reason for using this Iterator style is because internaly sockets are stored in a doubly-linked list. Using array property would mean linear search which is really slow.
Connect itself doesn’t block in any platform. However if you specify a hostname (as opposed to IP) as the argument it must be first translated to an IP address by DNS servers. If the hostname is invalid you can get visible “bumps”. Technicly speaking this is not a Windows only issue but I noticed that windows has most visible delays. I’m working on making the DNS lookup non-blocking too.