Introductory Note
I originally wrote this article in the days of Indy 8.0. Most of the article still applies and is very useful for newer versions of Indy. If you like this article and would like to read many more in depth articles, please check out Indy in Depth.
Indy is Blocking
Indy uses blocking socket calls. Blocking calls are much like reading and writing to a file. When you read data, or write data, the function will not return until the operation is complete. The difference from working with files is that the call may take much longer as data may not be immediately ready for reading or writing (It can only operate as fast as the network or the modem can handle the data).
For example, to connect simply call the connect method and wait for it to return. If it succeeds, it will return when it does. If it fails, it will raise an exception.
Blocking is NOT Evil
Blocking sockets have been repeatedly attacked with out warrant. Contrary to popular belief, blocking sockets are not evil.
When Winsock was "ported" to Windows, a problem quickly arose. In Unix it was common to fork (kind of like multi threading, but with separate processes instead of threads). Unix clients and daemons would fork processes, which would run, and use blocking sockets. Windows 3.x could not fork and did not support multi threading. Using the blocking interface "locked" user interfaces and made programs unresponsive. So asynchronous extensions were added to WinSock to allow Windows 3.x with its shortcomings to use Winsock without "locking" the main and only thread of a program. This however required a different way of programming., and Microsoft and others vilified blocking vehemently so as to mask the shortcomings of Windows 3.x.
Then along came Win32 which could properly multi-thread. But at this point, everyone's mind had been changed (i.e. Developers believed blocking sockets were evil), and it is hard to "backtrack" once a statement has been made. So the continued vilification of blocking sockets continues.
In reality, blocking sockets are the ONLY way Unix does sockets. Blocking sockets also offer other advantages, and are much better for threading, security, and other aspects. Some extensions have been added for non-blocking sockets in Unix. However they work quite differently than in Windows. They also are not standard, and not in wide use. Blocking sockets under Unix still are used in almost every case, and will continue to be so.
Pros of Blocking
Easy to program - Blocking is very easy to program. All user code can exist in one place, and in a sequential order. Easy to port to Unix - Since Unix uses blocking sockets, portable code can be written easily. Indy uses this fact to achieve its single source solution. Work well in threads - Since blocking sockets are sequential they are inherently encapsulated and therefore very easily used in threads.Cons of Blocking
User Interface "Freeze" with clients - Blocking socket calls do not return until they have accomplished their task. When such calls are made in the main thread of an application, the application cannot process the user interface messages. This causes the User Interface to "freeze" because the update, repaint and other messages cannot be processed until the blocking socket calls return control to the applications message processing loop.TIdAntiFreeze
Indy has a special component that solves the User Interface freeze problem transparently. Simply add one TIdAntiFreeze anywhere in your application, and you can perform standard blocking Indy calls in your program without the User Interface being frozen.
The TIdAntiFreeze works by internally timing out calls to the stack and calling Application.ProcessMessages during timeouts. The external calls to Indy continue to block, and thus work exactly as without a TIdAntiFreeze otherwise. Use of a TIdAntiFreeze allows for all the advantages of blocking sockets, without the most prominent disadvantage.
Threading
Threading is almost always used with blocking sockets. Non-blocking sockets can be threaded as well, but they require some extra handling and their advantages are lost with blocking sockets. Threading will be discussed briefly as it is important in writing blocking socket servers. Threading can also be used to write advanced blocking clients.
Threading Advantages
Prioritization - Individual threads priorities can be adjusted. This allows individual server tasks or individual connections to be given more or less CPU time. Encapsulation - Each connection will be contained and less likely to interfere with other connections. Security - Each thread can have different security attributes. Multiple Processors - Threading automatically will take advantage of multiple processors. No Serialization - Threading provides true concurrency. Without threading all requests must be handled by a single thread. For this to work each task to be performed must be broken up into small pieces that can always execute quickly. If any task part blocks or takes time to execute all other task parts will be put on hold until it is complete. After each task part is complete, the next one is processed, etc. With threading, each task can be programmed as a complete task and the operating system will divide CPU time among the tasks.Thread Pooling
The creation and destruction of threads can be resource intensive. This is especially evident with servers that have short-lived connections. Such servers create a thread use it for very brief time and then destroy it. This causes for a very high frequency of creation and destruction of threads. An example of this is a time or even and web server. A single request is sent, and a simple answer returned. When using a browser to browse a web site hundreds of connections and disconnections to the server may occur.
Thread pooling can alleviate such situations. Instead of creating and destroying threads on demand, threads are borrowed from a list of inactive but already created list (pool). When a thread is no longer needed it is redeposited into the pool instead of being destroyed. While threads are in the pool they are marked inactive and thus do not consume CPU cycles. For a further improvement, the size of the pool can be adjusted dynamically to meet the current needs of the system.
Indy does support thread pooling. Thread pooling in Indy can be achieved via use of the TIdThreadMgrPool component.
Hundreds of Threads
With a busy server hundreds or even thousands of threads can easily be needed. There is a common misconception that hundreds of threads will instantly kill your system. This is a false belief.
With most servers threads spend most of their time waiting on data. While waiting on blocking calls the thread will be inactive. Thus in a server with 500 threads only 50 may be active at a single time.
The number of threads that your system has running now may surprise you. With only minimal services started and the following applications running:
My system has 333 threads currently created:
Even with 333 threads you can see that my CPU utilization is only at 1%. A heavily used IIS (Microsoft Internet Information Server) will create hundreds or thousands more threads.
Threads and Global Sections
Whenever multiple threads need to access data in a read/write fashion they must control access to the data to protect its integrity. This can be intimidating to programmers new to threading. However most servers do not require global data. Most servers perform compartmentalized functions. That is each thread performs an isolated task. Global read/write sections are an issue for many multi threaded applications, but global read/write sections typically are not an issue for most socket servers.
Indy Methodology
Indy is different than other Winsock components you may be familiar with. If you've worked with other components, the best approach for you may be to forget how they work. Nearly all other components use non-blocking (asynchronous) calls and act asynchronously. They require you to respond to events, set up state machines, and often perform wait loops.
For example, with other components, when you call connect you must wait for a connect event to fire, or loop until a property indicates that you are connected. With Indy you merely call Connect, and wait for it to return. If it succeeds, it will return when it does. If it fails, it will raise an exception. Working with Indy is very much like working with files. Indy allows you to put all your code in one place, instead of scattered throughout different events. In addition, Indy is much easier and more suited to threading.
How Indy is Different
Quick Overview Uses blocking calls Does not rely on events - Indy has events that can be used for informational purposes, but are not required. Designed to be threaded - Indy is designed with threading in mind. Indy can be used without threading however. Sequential programming DetailsIndy not only uses blocking calls (synchronous) but it acts as such. A typical Indy session looks like this:
with IndyClient do begin
本文地址：http://com.8s8s.com/it/it5386.htm