Introduction to Indy （转载）

Introduction to Indy Author: Chad Z. Hower Homepage: http://www.atozedsoftware.com

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.

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有