Indy Server, Internet, FTP and SMTP Delphi Components
Indy is short term for Internet Direct. Indy is a set of Open Source Delphi Components that allow developers to write network based software.
TidTCPServer and TidTCPClient Components
TidTCPServer and its counterpart TidTCPClient give the developer the ability to write enterprise level applications, peer-to-peer applications, as well as the ability to support TCP based protocols.
Socket Blocking is the way Indy operates. This means that when a server is communicating to a client it will not run any other code until it is done. This is okay in a multi-threaded environment, because every client has his own thread. That is why well designed use of Indy’s TCP servers scale very well.
By default, all of Indy’s server components use multiple threads. In a high demand system, clients will not wait. In that environment, multi-threaded programs are best.
Difference between Threads and Fibers in Multi-Threading of Indy Delphi Components
Multi-Threaded programming is not evil; however, to guide developers safely into the multi-threaded realm, Indy designers have given programmers the ability to use fibers. Fibers are NOT threads. However, fibers are more forgiving than threads when it comes to memory management because they run in a scheduled manner. This means that you do not have to worry about thread/GUI synchronizing. It is important to remember, however, that a well-designed multi-threaded application should be able to easily out-perform a fiber-based application. Again, by default Indy uses threads. To you, the developer, Indy makes this all very transparent. Simply pick the TidScheduler that suits you, and then go back to adding your event handling code. Using threads or fibers Indy components are still very fast.
Do you actually need to develop a server?
Remember, servers do not initiate connections. Clients initiate connections. If you are thinking of developing the next peer-to-peer file trading application. You are actually of thinking of developing an application that contains both a server and a client.
What port are you going to use for your new protocol?
In a nutshell, a port is simply a number that is used to identify connections using your protocol. In theory, it can be arbitrarily picked. In the past, I have picked the street address number where the code was written. However, be careful, there are many standard protocols out there that have their own port numbers. So be sure not to use one of those. If you do, you may run into problems running your code. To get more information about port numbers, you can go to the Internet Assigned Numbers Authority or www.iana.org.
Command Handlers: Whether or not to use Command Handlers of Indy Delphi Component
In past versions of Indy, TidTCPServer gave the developer the ability to choose to handle an OnExecute event for all of the data on the socket or use a wonderful device called Command Handlers. Command Handlers simplify socket management by allowing the developer to simply define text based commands for the new server. Command handlers also support parameters. It really does not get any easier than this. Now that behavior has been moved to a class call TidCmdTCPServer. We must not forget to set the CommandHandlersEnabled property to “True” when our server is instantiated.
Since we have chosen to use TidCmdTCPServer we cannot simply put one on a form. We must instead descend our own class based on TidCmdTCPServer and add all of our custom behavior to it. This was even the prefered way to go even when TidTCPServer supported command handlers. The option still remains to register the new server as a Delphi component. However, before the component is thoroughly tested, it might just be easier to leave that for a later time.
Whether it is developing a server for a standard protocol, or developing a server for some custom protocol Indy is a pretty solid way to go. The product is free, there is lots of support in the newsgroups, it comes with the source code, and best of all it works. The team that put this product together continues to improve it and their latest and greatest can be found at www.indyproject.org.