In the previous work, the author needs to develop a simple network data transfer program. This time is no exception because usually develop Delphi. Delphi 7 has two sets of TCP Socket components: Indy Socket Components (IDTCPCLIENT and IDTCPSERVER) and Delphi native TCP Socket Components (ClientSocket and ServerSocket). However, Borland has claimed that the ClientSocket and Serversocket components are about to be discarded, which is recommended to replace the corresponding INDY components. Therefore, the author used INDY. This article creates a simple set of TCP Socket data transfer applications on the INDy to demonstrate the use of IND. The Internet component set of open source code - Internet Direct (INDY) is a set of open source Internet components covering almost all popular Internet protocols. Indy is written with Delphi, which is included in the Borland development environment of Delphi 6, Kylix 1, and C Builder 6 and above. Indy once called WinShoes (Socket Library for Winsock - Windows), is built from a group of developers led by Chad Z. HOWER, and can find more information from Indy's site www.nevrona.com/indy and download Its new version. When the author wrote this article, the latest stability of IND is 9.0.14, and INDY 10 has also entered the Beta test phase. The Delphi 7 is INDY 9. On its component panel, there is a total of more than 100 IND components. Using these components You can develop TCP clients and server applications based on various protocols, and handle related encoding and security issues. You can identify the IND component by the prefix ID. Indy is blocking (blocking) When you use the Winsock development network application, read data from the socket or write data to Socket is asynchronous, so that you will not block the execution of other code in the program. When receiving data, Winsock sends a corresponding message to the application. This way of access is called a non-blocking connection, which requires you to respond to events, set state machines, and usually need a wait loop. Unlike the usual Winsock programming method, Indy uses the blocking Socket call mode. Blocking access is more like file access. When you read the data, or when writing data, the read and write functions will continue until the corresponding operation is completed. For example, initiated network connections simply call the Connect method and wait for it to return, if the method is successful, return directly, if it is not successfully executed, the corresponding exception will be thrown. Unlike document access, Socket calls may take a longer time because the data to be read may not be ready to immediately (largely depends on network bandwidth). Blocking Socket is not a demon (Evil), the blocking socket has been attacked without reason. In fact, blocking socket is not as terrible as usual. This also starts from the development of Winsock. When Socket is transplanted from UNIX to Windows, a serious problem immediately appeared. Unix supports forking forks, clients, and servers can be able to use the blocking Socket to be used to quickly use these processes.
Windows 3.x does not support the Fork and does not support multithreading. When using blocking sockets, the user interface will be "locked" and cannot respond to the user. To overcome this lack of Windows 3.x, Microsoft adds asynchronous extensions in Winsock so that Winsock does not "lock" the main thread (also unique thread). However, this requires a completely different programming method. So some people began strongly embraced Socket in order to cover up this weakness. When Win32 appears, it can support threads very well. But the incident has been difficult to change, and if you say it, you can't recover, so there is continued existence of obstructive Socket. In fact, blocking socket is still unique to Unix implementing socket, and it works very well. The advantages of blocked Socket are attempted to use blocking socket development applications on Windows: ○ Programming Simple-Blocking Socket application is easy to write. All user code is written in the same place and executed sequentially. ○ It is easy to transplant the UNIX - Since UNIX also uses blocking sockets, it is easier to write portable code. Indy is the use of this to implement its multi-platform support and a single source code. ○ Very good use of thread technology-blocked Socket is the order executed, and its inherent package characteristics make it easily used in the thread. The weakness of the blocked Socket has two sides, blocking sockets are no exception. One of its main disadvantages is to make the user interface user interface "freeze". When blocking Socket calls in the main thread of the program, since the Socket call is required to complete and return, the user interface message cannot be handled, so that UPDATE, Repaint, and other messages do not respond in time, resulting in a user interface. "Frozen". Use Tidantifreeze to confront "freeze" Indy uses a special component TIDANTIFREEZE to transparently solve the problem of "freezing" of customer program user interface. TIDANTIFREEZE interrupts the stack call in Indy internal timing, and calls the Application.ProcessMessages method to process the message during the interrupt, and the external Indy call continues to save the blocking state, as if the Tidantifreeze object does not exist. You only need to add a Tidantifreeze object anywhere in the program to avoid some significant disadvantages of all the advantages of the blocking socket in the client program. INDY uses thread technology to block SOCEKT usually use thread technology, INDY is also true. Starting from the bottom, INDY design is threaded. So use Id creation servers and client programs to be very similar under UNIX, and Delphi's rapid development environment and INDY's good package for Winsock makes it easier for applications. The INDY server model A typical UNIX server has one or more listening processes that keeps monitoring accessible client connection requests. For each customer who needs to serve, a new process is a new process to handle all of the customer's transaction. Such a process only processes a customer connection, and programming is very easy. INDY server works is very similar to UNIX servers, just Windows not supporting Fork like UNIX, but supports threads, so the INDY server assigns a thread for each client connection. Figure 1 shows the working principle of the INDY server. The INDY server component creates a listening thread that is separated by the application main thread to listen to the customer connection request. For each customer accepted, create a new thread to serve the customer, all related transactions related to this customer The thread is processed. Use the components TidthreadMgrPool, Indy supports the thread pool. Figure 1 INDY server working principle
Threads and INDY client components do not use threads. But in some advanced client programs, programmers can use Indy client components in custom threads to make user interfaces more friendly. Simple Indy Application Example The following will create a simple TCP client and a simple TCP server to demonstrate the basic use of Indy. The client is connected to the server using the TCP protocol and transmits the user to the server. Server supports two commands: DATA and Quit. Follow the data to be sent after the data command, and separate the command word DATA and data with spaces. The form layout establishes a project group to add a client program and a server project. The form layout of the client program and the server program is shown in 2 and Figure 3. The TIDTCPCLIENT component is placed on the client form, and the TIDTCPSERVER component is placed on the server program. To prevent the customer program from "freeze", place the Tidantifreeze component on its form. A TListBox component is placed on a form of a client and a server program to display communication records. Figure 2 Simple TCP customer program form
Figure 3 Simple TCP server program form list
