Building a Server Application in Delphi

So how can we write client server applications with Delphi? Well, Delphi 6+ comes with a group of Internet components called Indy, which implements various protocols and presents them neatly in the form of components. Since our primary aim is to create client-server applications, we are only going to focus on them. But I want to go into a bit of background on how Indy works, so that you have some knowledge of how to implement other components that you might want to use in the future.

Indy provides server and client components for almost all the protocols that you can find out there, anything from HTTP to SMTP. What I will do is to explain in general terms how indy implements or deals with servers and clients. I must point out, in the interest of fairness, that there are other free Internet components that you can use such as ICS, that can be used with Delphi. I choose to use Indy because it makes it easy to built Internet-based applications, and also because I've been using it for as long as I can remember without any major problems. The only problem you'll find is that there is not a whole lot of documentation around on how to use these components, particularly the newer versions.

Indy is different  from most other Internet components in the following ways:

• Indy uses the blocking socket API.
• Indy does not rely on events. Indy has events that can be used for informational purposes, but are not required.
  
• Indy is designed for threads. Indy can be used without threads, however.
  
• Indy is programmed using sequential programming.
  
• Indy has a high level of abstraction. Most socket components do not effectively isolate the programmer from stack. Most socket components instead of isolating the user from the complexities of stack merely pass them on with a Delphi / C++ Builder wrapper.

Not all of the above points will make sense to you and I will not go into much detail about them in this article, but there are two terms mentioned that I want to explain. 

First I want to explain the term "blocking." What do we mean by blocking? Well it is a term that describes one of two methods of programming sockets under Windows, the other being non-blocking. Indy uses blocking socket calls. This means that indy waits until a operation is completed when it makes a call. For example, to connect a socket, you simply call the connect method and wait for it to return. If the connect method succeeds it will connect, if it does not, it will show an exception message.

Non-blocking calls on the other hand, handle things differently. For example when connecting a socket, the connect method will return BEFORE the socket is connected.  When the socket is connected, an event will occur. This requires that the communication logic be split up into many procedures, or that polling loops be used. So the blocking method makes things easier and straightforward.

Threads

The other term I want to explain is thread. A thread is a separate preemptive execution path. Using threads allows for different execution paths to be executed simultaneously.  Threads allow your  application to do more than one thing at a time.

Threading is available even if you only have one CPU. In reality only one thread is executing at a time, however the operating system preemptively interrupts the thread and switches to another one. Each thread is only executed for a very short time each pass. This allows for tens of thousands of "slices" to occur per second.

Because the switching is preemptive and unpredictable, to the software the threads appear to be executing in parallel, and software must take precautions about this. In multiple CPU systems threads can actually execute in parallel, however each CPU can in reality still only execute one thread at a time. So threading plays a major role in Indy, and it is one of the reasons why I think indy has the best and most practical Internet components available today.