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 Source Code
unit ServerMain; interface
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
