Some differences between Delphi Indy and sockets

About the Indy--delphi Internet control set

Delphi 2010 contains a large number of Indy controls, online find some information to go to the blog below to share.

Have you ever developed an Internet program with Delphi? Is it always worrying why the Fastnet component has no source code? There are many problems, do not look at the source code, really do not know what the problem. Do you also feel that the Fastnet component does not support enough network protocols? Don't worry now, there's a rich, easy-to-use, open-source free Internet control set that can solve your worries. This set of controls is Indy.

What is Indy? What functions does it have? How to use it? Let me slow down.

The full name of Indy is Internet Direct (also known as Winshoes), an open source set of Internet controls that supports most popular Internet protocols, including TCP, UDP, DNS, ICMP, FINGER, FTP, GOPHER, HTTP, POP3, SMTP, TELNET, whois, and so on, support BASE64, MD2, MD4, MD5 and other codecs, and provide client and server controls for popular Internet protocols. The client and server controls of the Indy control set have complete, detailed source code routines and Help files that allow users to easily and quickly build various server programs, such as Web servers, telnet servers, IRC servers, TCP, UDP servers, etc. These servers are supported by multithreading. Users can also easily write a variety of client programs, such as email, FINGER, FTP, PING, Telnet and so on. The famous OICQ use the protocol is UDP, with Indy You can use UDP server and UDP client to write a and Oicq to contend with the east.

Indy is a development repository that is completely based on the socket blocking mode (discussed later) and now supports Borland Delphi, C + + Buider, and the latest Kylix (Delphi in Linux). DELPHI 7.0 will use Indy as its basic component of the Internet, thus Indy's strength.

The rich routines offered by Indy are the perfect textbook. Compile a few routines first to see the powerful features of Indy. To skillfully use the good Indy, you have to learn a lot of these routines and reference help files.

Readers familiar with Winsock programming must be surprised to find out why Indy is completely based on the socket blocking mode of operation. Asynchronous mode (non-blocking mode) is a major feature of Winsock, why not?
In fact, most Internet programs under Windows use asynchronous mode, which is related to the history of Winsock. When Winsock was ported to Windows, the Windows operating system was still Windows 3.1, and Windows 3.1 did not support multithreading, unlike UNIX, which could use fork to run multiple processes. In the case of Windows 3.1, if you use blocking mode, the user interface is locked during communication and the program is not responding, and in order to avoid this, Winsock introduces the new feature of asynchronous mode. The use of asynchronous patterns to compile Internet programs is a classic dogma of Windows programmers. However, with the advent of new Windows operating systems, such as Windows 95, NT, 98, ME, 2000, and so on, these operating systems begin to support multithreading. The doctrine of asynchronous mode is still popular, so many programmers subconsciously refuse to use blocking mode.
In fact, the socket under UNIX only supports blocking mode (now Unxi socket has some new non-blocking features, but most applications still use blocking mode). The blocking mode has several advantages over asynchronous mode:
Programming is simpler, and all the code that handles the socket can be put together in a sequential execution without being scattered across different event-handling code segments.
More easily ported to UNIX, using Indy Delphi program, can not do too much (or do not do) modification, you can put Windows Delphi source code to Linux, with Kylix to compile the network program under Linux.
Easier to use in multi-threaded programs, because the blocking mode of code can be put together, it can be very convenient to wrap the code inside the thread to use, rather than asynchronous mode, you need to set different processing code for different events.

For simplicity, reliability and efficiency, the Indy is based on blocking mode. Blocking mode waits for the task to complete before returning, so that the program cannot process the user interface message when the blocking task runs in the main thread. Indy provides a control tidantifreeze to solve this problem. As long as in your program, simply add a Tidantifreeze control to any place (just put it on the form), do not need to write any code (the maximum time to change the timeout), can be a good solution to the user interface does not respond to the problem.

Here are two examples of code that shows how concise the Indy control's program code is compared to other program code for Internet controls that use asynchronous mode:

Code One: The program code for the Indy control (Indyclient represents the general form of the Indy control)

With Indyclient do begin

Connect;

Try

Write your processing code here

Finally

Disconnect;

End

End

Code two: program code for other controls (Socketcomponent for general internet controls)

Procedure Tformmain.testonclick (sender:tcomponent);

Begin

With Socketcomponent do begin

Connect; Try

While not Connected do begin

If IsError then BEGIN

Abort;

End

Application.processmessages;

Outdata: = ' Data to send ';

While length (Outdata) > 0 DO begin

Application.processmessages;

End

Finally Disconnect; End

End

End

Procedure Tformmain.onconnecterror;

Begin

IsError: = True;

End

Procedure Tformmain.onread;

Var

I:integer;

Begin

I: = Socketcomponent.send (Outdata);

Outdata: = Copy (Outdata, i + 1, MaxInt);

End

About Indy's brief introduction is here, the interested friend will go to download a use, you will certainly like it.

The similarities and differences between Indy and sockets

1.

Compare the similarities and differences between the Serversokcet and Clientsocket and the Idtcpserver and idtcpclient two groups of communication components:

The socket supports the same transfer of data and supports the asynchronous transfer of data. The IDTCP only supports synchronous transfer of data.

Serversokcet and Clientsocket are non-blocking, event-triggered.

Idtcpserver and Idtcpclient are block-based, multi-threaded.

Idtcpserver for each connected user to establish a separate thread, programming is more convenient.

Use Indy to complete the port, after the pressure test, found that can withstand 600 concurrent users, of course, this is related to personal programming level, do not good, more than 100 concurrent users are difficult to accept

2.

Q: A network system, when the client mutual information sent, while requiring records to be saved to the server database, ask the server side/client to use Indy specific which control is more reasonable?

A: Idtcpclient/idtcpserver/idudpclient/idudpserver are available. Mainly see the specific application requirements

Idtcpclient/idtcpserver will establish a long-time connection at runtime until it exits, and the Idudpclient/idudpserver is able to send data to the specified IP and port, which can be determined by the network. The resources they consume also differ.

3.

TcpClient TCPServer and Idtcpclient idtcpserver are not the same control, and then D7,
They belong to different templates (Intenet,indy Client,indy server) and also have different properties, methods, and events.
In addition, Intenet's TCPServer receives the data is automatically establishes the thread to trigger the OnAccept event, therefore must establish a thread in this event, may refer to the demo Netchat example.

1. Blocking mode programming recommended with Indy Idtcpclient Idtcpserver
2. Non-blocking modes are recommended for use with D7 Component->install PACKAGES->ADD->DELPH7\BIN\DCLSOCKETS70. BPL to Add.
3. Tcpclient,tcpserver the demos in D7 is a blocking mode that is used when the client connects and establishes a thread to handle the communication problems with the client. blockmode:=bmthreadblocking;
4. Tcpclient,tcpserver can also work in non-blocking mode, blockmode:=bmnoblocking; it's like Clientsocket ServerSocket, but TCPCLIENT Can be like Clientsocket and Onread,onwrite, and TCPServer did not see like ServerSocket onclientread,onclientread.
5. Look at the source code of TCPServer, and found that he and tcpclient as the end of the tbasesocket, then there should be onread,onwrite.
6. If we make a procedure tcpserverreceive like TcpClient (Sender:tobject; Buf:pansichar; var datalen:integer), you write processing code, and then tcpserver1.onreceive:=tcpserverreceive; OnSend and so on, it should be.
7. This method is not tested, but the principle is that the TCPServer onreceive,onsend is not visible at design time, not equal to his

Some of the differences between Delphi Indy and sockets