| est 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
Details
Indy not only uses blocking calls (synchronous) but it acts as such. A typical Indy session looks like this: with IndyClient do begin
Connect; Try
// Do your stuff here
finally Disconnect; end;
end;
Other components may look something similar to this: 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;
Most components do not do a very good job of isolating the programmer from stack. Many components instead of isolating the user from the complexities of stack merely pass them on or provide a Delphi/CB wrapper for the stack.
The Indy Way
Indy is designed from the ground up to be threadable. Building servers and clients in Indy is similar to the way Unix servers and clients are built, except that it is much easier, because you have Indy and Delphi. Unix apps typically call the stack directly with little or no abstraction layer.
Typically Unix servers have one or more "listener" processes which looks for incoming client requests. For each client that it needs to serve, it will fork a new process to handle each client. This make programming very easy as each process deals with only one client. The process also runs in its own security context, which can be set by the listener or the process based on credentials, authentication, or other means.
Indy servers work very similarly. Windows unlike Unix does not fork well, but it does thread well. Indy servers allocate a thread for each client connection.
Indy servers set up a listening thread that is separate from the main thread of the program. The listener thread listens for incoming client requests. For each client that it answers, it spawns a new thread to service that client. The appropriate events are then fired within the context of that thread.
Overview of Indy Clients
Indy is designed to provide a very high level of abstraction. Intricacies and details of the TCP/IP stack are hidden from the Indy programmer.
A typical Indy client session looks like this: with IndyClient do begin Host := ''''zip.pbe.com''''; // Host to call Port := 6000; // Port to call the server on Connect; Try // Do your stuff here finally Disconnect; end; end;
Overview of Indy Servers
Indy server components create a listener thread that is separate from the main thread of the program. The listener thread listens for incoming client requests. For each client that it answers, it then spawns a new thread to service that client. The appropriate events are then fired within the context of that thread.
Practical Examples
The following examples should normally be encapsulated into descendant components for easy reuse, but for the sake of demonstration the examples will be done as simple applications. Several projects will be presented to show a variety of situations. These examples are also available as a zip file.
Example 1 - Zip Code Lookup
The first project has been designed to be as simple as possible. Zip Code Lookup will allow a client to ask a server what city and state a zip code is for.
For those of you outside the United State who may not know what a zip code is, a zip code is a US postal code that specifies a postal delivery area. Zip codes are numeric and 5 digits long.
Protocol
The first step in building a client or server is to understand the protocol. For standard protocols this is done by reading the appropriate RFC. For Zip Code Lookup a protocol has been defined and is below.
Most protocols are conversational and plain text. Conversational means that a command is given, a status response follows, and possibly data. Protocols that are very limited are often not conversational, but are still plain text. Zip Code Lookup is plain text, but not conversational. Plain text makes protocols much easier to debug, and also to interface to using different programming languages and operating systems.
Upon connection the server will respond with a welcome message, then accept a command. That command can be "ZipCode x" (Where x is the zip code) or "Quit". A ZipCode command will be responded to with a single line response, or an empty line if no entry exists. Quit will cause the server to disconnect the connection. The server will accept multiple commands, until a Quit command is received.
Server Sour 上一页 [1] [2] [3] [4] [5] 下一页 | 
