Introduction to Indy （转载）

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 b

[1] [2] [3] [4] [5]  下一页

Copyright ＠ 2007-2012 敏韬网(敏而好学，文韬武略--MinTao.Net)（学习笔记） Inc All Rights Reserved.
闵涛 E_mail:admin@mintao.net(欢迎提供学习资源)

鄂公网安备 42011102001154号

站长：MinTao ICP备案号：鄂ICP备11006601号-18