Use of Indy10 controls (2) Tidtcpserver component Learning

Use of Indy10 controls (2) Tidtcpserver Component Learning (2012-05-18-15:16:53) reproduced

Tags: indy10lazarusidtcpserver

Category: Indy10

The following from the English original Help file, Wen Huan English is not good, translated long time. Don't scold me for the wrong place.

Tidtcpserver = Class (Tidcomponent)

Description

Tidtcpserver is a tidcomponent descendant this encapsulates a complete, multi-threaded TCP (transmission Control Protocol) Server.

Tidtcpserver is a subclass of Tidcomponent that encapsulates a full multithreaded TCP service.

Tidtcpserver allows multiple listener threads that listen for client connections to the server, accept new client Connecti ONS, and Hand-off execution of the client task to the server. By default, at least one listener thread was created for the server. For servers with multiple network adapters, additional socket Bindings can is created that allow the server to listen for Connection requests using the IP address for the selected network adapter (s).

Tidtcpserver allows multiple listener threads to listen for client-to-server links, accept new customer service links, and handle customer tasks. By default, at least one listener thread is created in the server. In multi-NIC servers, additional sockets bindings are created to listen for connection requests from specific network adapter IP addresses.

If IP Version 6 addresses is enabled for the server, an additional listener thread was created for each adapter specifical Ly for connections using the IPV6 address family.

If the server is enabled for IPV6, an additional listener thread will be created to use the IPV6 address family for a link service that does not have a network card.

Tidtcpserver allows multiple simultaneous (same moment) client connections, and allocates a separate unit of execution for each CL Ient connecting to the server. Each client connection represents a task which is managed by the Scheduler for the server. Listener threads Use the Scheduler to create a executable task for each client connection.

Tidtcpserver allows multiple client links at the same time and assigns a separate execution unit to a client link . Each customer link represents a task that is Scheduler managed. The listener thread uses Scheduler to create a task for each customer link.

The Scheduler handles creation, execution, and termination of the tasks for client connections found in contexts. The Contextclass property indicates (indicated, indicated) the type of executable task created for client connections and added to Context S.

Scheduler in contexts the creation, execution, termination, and Contextclass properties of the Client Connection Processing taskindicate the type of task that can be performed.

There is basically the types of schedulers available for tidtcpserver:thread-based and fiber-based. Each are designed to work with a specific type of executable task that represents (representative) the client connections. There is further (further) Scheduler refinements (improved) that allow a pool of pre-allocated Threads, or Threads which perform Sch Eduling for dependent fibers.

tidtcpserver has two basic schedulers: Thread-based and fiber-based. They are designed for specific, executable tasks that connect on behalf of the customer.

The default Scheduler implementation in Tidtcpserver uses a, Thread to represent, each client connection. Threads is a common feature found on all platforms and Operating Systems hosting the Indy library.

in the Tidtcpserver The default scheduler implementation in is to use a thread to represent each client connection. Threads are a common feature that can work on different operating systems.

But there is performance (performance) and resource (resources) limitations imposed (imposed) by the platform or Operating System on the number of threads that can be created. On Windows, for example, the number of threads was limited by the available virtual memory. By default, every thread gets one megabyte (MBytes) of the stack space and implies (meaning) a theoretical (theoretically) limit of 2028 threads. Reducing the default stack size would allow more threads to be created, but would adversely impact system performance. In addition, threads is pre-emptively (preemptive) scheduled by the host operating system and allow no control over execution of The thread process.

However, due to performance and resource constraints, the operating system can only create a limited number of threads. For example, in Windows, the number of threads depends on the size of available virtual memory. By default, the stack for each thread requires a megabyte, which means there can be only 2028 threads in theory. Reducing the default stack size increases the number of threads, but it can affect system performance. The thread is preemptive and is being dispatched by the operating system, and we can't control it.

Windows addresses these issues by providing the fibers API. Essentially, fibers is a light-weight thread. Fibers require fewer resources that threads. Fibers can manually scheduled in the server, and run in the context of the the thread that schedules them. In other words, fibers is not pre-emptively scheduled by the Operating System. The Fiber runs when its thread runs. As a result, servers using the Fiber API can be more scalable (scalable) than contemporary (same era) thread-based implementations.

In order to solve this problem, Windows provides the fiber API, fiber is a lightweight thread, requires less resources. A fiber can be called manually in the service and is in the context of the thread.

The Fiber API is very different from the Thread API (even on the Windows platform). To hide these APIs differences, and to preserve code portability to non-windows platforms, the Scheduler in Tidtcpserver PR Ovides an abstraction that masks the differences:the Yarn.

Effect: The Fiber API is very different from the thread API, and in order to hide these differences, the yarn class is provided.

Q:What do I get when you weave threads and fibers together? A:yarn.

While Tidtcpserver does not with fibers unless a Scheduler supporting fibers is assigned (tidscheduleroffiber), the Yarn AB Straction is a important one that's central to the use of the Scheduler. When the Scheduler supports Threads, it deals is only with a Yarn at the Thread level. When the Scheduler supports fibers, it deals and a Yarn at the Fiber level.

tidtcpserver do not use fiber if not specified.

The Contextclass property for the server was used to create the unit of execution for the client connection, and also uses The Yarn abstraction.

The Contextclass property of the service is used to create execution units for customer links, which are also abstracted by yarn.

Tidtcpserver provides properties and methods that allow configuration of the server and listener threads, including:

Tidtcpserver provides the properties and methods to configure the service and listener threads, including:

Active Startup

Defaultport Default Port

Bindings

Listenqueue

MaxConnections

Iohandler IO Processing

Intercept Interrupt

Reusesocket

Terminatewaittime

Onafterbind

Onbeforelistenerrun

Onlistenexception

The Tidtcpserver architecture provides properties and methods that allow controlling execution of the client connection Ta SKS for the server, including:

the Tidtcpserver schema provides properties and methods that allow control over the execution of client link tasks. include:

Contextclass

Scheduler

Onbeforeconnect

OnConnect

OnExecute

OnDisconnect

Onexception

During initialization of the Tidtcpserver component, the following resources is allocated for properties in the server:

When the Tidtcpserver control is initialized, the resources for the following properties in the service are assigned:

Bindings

Contexts

During initialization of the Tidtcpserver component, the following properties is set to their default values:

Default value for initialization phase:

Property Value

Contextclass Tidcontext class Reference

Terminatewaittime (5 seconds)

Listenqueue Idlistenqueuedefault

At runtime, Tidtcpserver was controlled by changing the value of its Active property. When Active was set to True, the following actions performed as required to start the server including:

at run time, Tidtcpserver is controlled by changing the value of the active property. When active is set to true, the following actions are performed:

Bindings is created and/or initialized for IPV4 and IPV6 addresses.

Bind IP Address

Ensures that's Iohandler is assigned for the server.

Verify that the IO processor is assigned.

Ensures a Scheduler is assigned for the server.

Confirm Scheduler is already assigned.

Creates and starts listener threads for Bindings using the thread priority tphighest.

Create and start a listener thread on each of the bingdings.

When Active was set to False, the following actions be performed as required to stop the server including:

When the active property is set to False, execute:

Terminates and closes the socket handle for the any listener threads.

Terminates a listener thread and closes the socket.

Terminates and disconnects any client connections in contexts, and yarns in Scheduler.

Terminate and disconnect all customer links.

Frees an implicitly (hidden) created Scheduler for the server.

Release a scheduler that has been secretly built.

Changing the value in Active in the IDE (design-time) have no effect other than storing the property value that's used at Runtime and during component streaming.

The design phase changes the active value without any effect, except that the stored value is working at run time.

While the server was Active, listener thread (s) is used to detect and accept client connection requests. When a connection request was detected, the Scheduler in the server instance was used to acquire the thread or fiber that CO Ntrols execution of the task for the client connection. The Iohandler in the server was used to get a iohandler for the client connection.

When the service is activated, the listener thread is used to probe and accept customer requests, and when a link is detected, the scheduler in the service instance is used to obtain the thread or fiber that controls the execution of the task. The Iohandler in the service is used to obtain a iohandler for the client connection .

A client connection request can be refused for a number of reasons. The listener thread may get stopped during processing of the request, or the attempt to create a client Iohandler fails be Cause of an invalid socket handle.

A client connection request may be rejected for some reason. The listener thread may stop processing the request or attempt to create a client Iohandler failure because of an invalid socket processing .

The most common error occurs if the number of the client connections in contexts exceeds the number allowed in maxconnection S. In this situation, a message is written to the client connection that indicates the condition and the client Connectio n is disconnected.

The most common error occurs when a customer connection exceeds the maximum number of connections. In this case, a message will be sent to the client, and the link will be closed.

If the connection is refused due to any other exception, the onlistenexception is triggered.

If the link is rejected because of a different exception, onlistenexception will be used to track.

If no error or exception is detected for the connection request, a tidcontext are created for the client connections execut Able Task. Procedures that trigger the OnConnect, OnDisconnect, and OnExecute event handlers is assigned to the context. The context is then given to the Scheduler for execution using its native thread or fiber support.

If there is no error in the link request, or if the exception is detected, a client link task is created Tidcontext. Use Context when dealing with OnConnect, OnDisconnect, OnExecute these events . This context will be given to Scheduler.

The executable task for the client connection is fully self-contained and controlled using the OnConnect, O Ndisconnect, and OnExecute event handlers. OnConnect and OnDisconnect are optional, and should is used only to perform simple tasks that is not time consuming (consumption). Using Synchronized method calls that access the main VCL thread is highly discouraged (discouraged, discouraged). Use OnExecute to control the interaction (interaction) between the client and the server during the lifetime of the client connect Ion.

Tidtcpserver does not implement support for any given protocol used for communication exchanges between clients and the SE RVer. Tidtcpserver can is used as a base class to create custom TCP server descendants this support specific protocols.

Use Tidcmdtcpserver for a TCP server, includes Tidcommandhandler and Tidcommand support.

Copyright (c) 1993-2004, Chad Z hower (Kudzu) and the Indy Pit Crew. All rights reserved.

Use of Indy10 controls (2) Tidtcpserver component Learning