C ++ network programming ace-related data collection

 

Xiaofei's website http://www.flyingdonkey.com/mavida C ++ Web Programming

Http://www.flyingdonkey.com/cgi-bin/LB5000MX/leoboard.cgi
Weizone our http://www.weizone.com/forumdisplay.php community? FID = 22 & page = 1 ACE network communication programming Edition

Loveunix Technology Forum http://www.loveunix.com/viewthread.php? Tid = 29276
Hxh (hexing river) column http://blog.csdn.net/hxhbluestar/category/25379.aspx ACE network programming
Ace self-adaption communication environment discussion http://www.huihoo.org/chat/ace_20030702.html
[Ace technology paper] I. Ace self-adaption communication environment: an object-oriented network programming toolkit for developing communication software
Ace program entry function replacement mechanism analysis
[Ace technology paper] wrapper facade: a structural model used to encapsulate functions in a class
[Ace technology paper] tri-ipc sap: C ++ packages for efficient, portable, and flexible network programming
[ACE technical proceedings] 4. Oo encapsulation of ACE lightweight OS concurrency mechanism
[ACE technical proceedings] v. C/C ++ thread-specific storage: object behavior modes used to access the "per-thread" state
Ace class structure [PDF]
Ace self-adaption communication environment
Douglas C. Schmidt
I. Ace Overview
Ace adaptive communication environment (Adaptive Communication Environment) is a free-to-use, open-source object-oriented (OO) framework ), many core modes for concurrent communication software are implemented. ACE provides a rich set of reusable C ++ wrapper facade and framework components to complete common communication software tasks across multiple platforms, including: multi-channel event separation and event processor allocation, signal processing, service initialization, inter-process communication, shared memory management, message routing, distributed service dynamic (heavy) configuration, concurrent execution and synchronization, and so on.
Ace is intended for developers of high-performance and real-time communication services and applications. It simplifies the development of OO network applications and services that use inter-process communication, event Multi-Channel Separation, explicit dynamic links, and concurrency. In addition, through the dynamic link between the service and the application at runtime, ACE also automates the system configuration and reconfiguration.
Ace is continuously improving. Riverace (http://www.riverace.com) Uses Open Source Business models to provide commercial support for Ace. In addition, many members of the ACE development team are currently conducting the ace orb (TAO, http://www.cs.wustl.edu /~ Schmidt/tao.html) development work.
Ii. Benefits of using ace
Ace has the following advantages:
L enhanced Portability: with the help of ACE components, it is easy to write concurrent network applications on an OS platform, and then quickly port them to various other OS platforms. Besides, because Ace is an open-source free software, you don't have to worry about being locked to a specific operating system platform or compiler.
L better software quality: Ace design uses many key models that can improve software quality. These quality factors include communication software flexibility, scalability, reusability and adequacy.
L higher efficiency and predictability: Ace has been carefully designed to support a wide range of application Quality of Service (QoS) requirements, including low response waiting time for latency-sensitive applications and high performance of high-bandwidth applications, and real-time application predictability.
L easier to switch to standard advanced middleware: Tao uses reusable components and modes provided by Ace. It is the development source code and standard implementation of CORBA, and optimizes high-performance and real-time systems. To this end, ACE and Tao are designed to work together well to provide a comprehensive middleware solution.
Iii. Ace Structure and Functions
The key components in ACE and their hierarchies are displayed:
The structure and components of each layer are described as follows.
Iv. Ace OS Adaptation Layer
This layer is directly located on the local OS API written in C. It provides a lightweight POSIX OS-like adaptation layer to shield other layers and components in ACE and the following Platform proprietary features associated with OS APIs:
L concurrency and synchronization: The ace Adaptation Layer encapsulates OS APIs for multithreading, multi-process, and synchronization.
L inter-process communication (IPC) and shared memory: The Adaptation Layer of ACE encapsulates OS APIs for local and remote IPC and shared memory.
L multi-channel event separation mechanism: the adaptation layer of ACE encapsulates OS APIs for synchronous and asynchronous multi-channel separation of I/O, timer, signal, and synchronization events.
L explicit dynamic link: The Adaptation Layer of ACE encapsulates the OS API for explicit dynamic link. Explicit Dynamic Links allow you to configure application services during installation or running.
L file system mechanism: the adaptation layer of ACE encapsulates OS file system APIs for operating files and directories.
The portability of the ace OS Adaptation Layer enables ace to run on many operating systems. Ace has been transplanted and tested on a wide range of OS platforms, including Win32 (that is, on Intel and Alpha platforms, use msvc ++, Borland C ++ builder, winnt 3.5.x, 4.X, 2000, Win95/98, and Wince of IBM Visual Age, Mac OS X, and Unix of most versions (for example, solaris 1. x, 2.x, and sgi irix 5. X and 6.x, DG/UX, HP-UX 9.x, 10. X and 11.x, DEC/Compaq
UNIX 3. x, 4.X, and Aix 3. x, 4.X, unixware, SCO, and freely available UNIX implementations, such as Debian Linux 2.x, RedHat Linux 5.2, and 6. X and 7.x, FreeBSD and NetBSD), real-time operating systems (such as lynxos, VxWorks, chorus classix 4.0, QNX neutrino, RTEMS, and PSOs), MVS openedition, and Cray unicos.
Given the abstraction provided by the ace OS adaptation layer, all these platforms use the same code tree. This design greatly enhances the portability and maintainability of ACE. In addition, there is Java version of ACE available (http://www.cs.wustl.edu /~ Eea1/jace.html ).
V. C ++ wrapper facade of the OS Interface
You can directly write highly portable C ++ applications on the ace OS adaptation layer. However, most ace developers use the C ++ wrapper facade layer shown in. These interfaces encapsulate and enhance local OS concurrency, communication, memory management, event multiplexing, dynamic links, and file system APIs ), ace wrapper facade simplifies application development. Applications can combine and use these packages by selectively inheriting, aggregating, and/or instantiating the following components:
L concurrency and synchronization components: Ace abstracts local OS multithreading and multi-process mechanisms such as mutex and semaphore to create advanced OO concurrency abstractions, such as active objects) and polymorphic future ).
L IPC and file system components: Ace C ++ packages local and/or remote IPC mechanisms, such as socket, TLI, Unix FIFO and Stream pipelines, and Win32 Named pipelines. In addition, the ace C ++ package also encapsulates the OS file system API.
L memory management component: the ace memory management component provides flexible and scalable abstraction for managing the shared memory between processes and the Dynamic Allocation and release of heap memory in processes.
The ace c ++ packaging provides many of the same features as the ace OS adaptation layer. However, these features are constructed using C ++ classes and objects, rather than independent C functions. Such oo packaging helps reduce the effort required to learn and use ACE correctly.
For example, the use of C ++ improves the robustness of applications, because C ++ packaging is strongly typed. Therefore, the compiler can detect type system violations during compilation rather than runtime. On the contrary, it is impossible to detect type system violations of C-level OS APIs such as socket or file system I/O during runtime.
Ace uses many techniques to reduce or eliminate additional performance overhead. For example, Ace uses C ++ inline extensively to eliminate additional method call overhead; such overhead can be brought by the additional types of security and abstraction layers provided by the OS adaptation layer and C ++ packaging. In addition, Ace avoids virtual functions for packaging with high performance requirements, such as the socket and file I/O send/Recv methods.
Vi. Framework
ACE also contains an advanced network programming framework that integrates and enhances the lower-level C ++ wrapper facade. This framework supports dynamic configuration of concurrent distributed services into applications. The ACE framework includes the following components:
L event multiplexing components: Ace Reactor (Reactor) and proactor (front camera) are scalable object-oriented multiplexing splitters that distribute application-specific processors, to respond to various types of I/O, timer, signal, and synchronization events.
L service initialization component: the ace acceptor and connector (connector) components decouple the active and passive initialization tasks with the application-specific tasks executed by the communication service after initialization.
L service configuration component: ACE service configurator supports application configuration. Services of these applications can be dynamically assembled at installation time and/or runtime.
L layered stream component: the ace stream component simplifies the development of communication software applications consisting of layered services such as user-level protocol stacks.
L orb adapter component: Through orb adapter, Ace can be seamlessly integrated with single-line and multi-thread CORBA implementations.
ACE framework components facilitate the development of communication software, which can be updated and expanded without modifying, recompiling, relinking, or frequently restarting running applications. In ace, such flexibility is achieved by combining the following elements: (1) c ++ language features, such as templates, inheritance and dynamic binding, (2) design patterns, for example, the abstract factory, policy and service configurator, and (3) OS mechanism, such as explicit dynamic links and multithreading.
VII. distributed services and components
In addition to the OS adaptation layer, C ++ wrapper facade, and framework components, ACE also provides a standard distributed service library encapsulated into self-contained components. Although these service components are not strictly components of the ACE framework library, they play two roles in ACE:
1. break down the "blocks" of reusable distributed applications: These service components provide reusable Implementation of Common distributed application tasks, such as name services, Event Routing, logs, time synchronization, and network locking.
2. common examples of demonstrating ace components: These distributed services also demonstrate how to use reactor, service configurator, acceptor, connector, active object, and IPC packages such ace components to effectively develop flexible, efficient, and reliable communication software.
8. Advanced Distributed computing middleware components
Even with a communication framework like Ace, developing robust, scalable, and efficient communication applications is still challenging. In particular, developers must master many complex OS and communication concepts, such:
L Network Addressing and service identification.
L Represents conversion, such as encryption, compression, and byte sequence conversion between heterogeneous terminal systems.
L process and thread creation and synchronization.
L System Call and database routine of the communication (IPC) mechanism between local and remote processes.
Using Advanced Distributed computing middleware such as CORBA, DCOM, and Java RMI can reduce the complexity of developing communication applications. The Advanced Distributed computing middleware resides between the client and the server and can automatically complete many troublesome and error-prone aspects of distributed application development, including:
L authentication, authorization, and data security.
L service positioning and binding.
L register and enable the service.
L multi-channel event separation and dispatch.
Message frames are implemented based on byte stream-oriented communication protocols such as TCP.
L indicates the conversion of network byte order and parameter reorganization.
To provide these features to communication software developers, Ace binds the following advanced middleware applications:
1. the ace orb (TAO): Tao is a real-time implementation of CORBA built using the framework components and modes provided by Ace, including features such as network interfaces, OS, communication protocols, and CORBA middleware components. Based on the standard omg corba reference model, Tao has been designed with enhancements to overcome the disadvantages of traditional ORB for high performance and real-time applications. Like ace, Tao is also an open source software that can be freely used.
2. Jaws: Jaws is a high-performance, Self-Adaptive Web server built using the framework components and modes provided by Ace. Jaws is constructed as a "framework ". The overall jaws framework includes the following components and frameworks: Event multi-path dispatcher, concurrency policy, I/O policy, protocol pipeline, protocol processor, and cache Virtual File System. Each framework is constructed into a group of collaboration objects, which are implemented by combining and extending the components in Ace. Jaws is also an open source software that can be freely used.
9. Home Page
Ace home: http://www.cs.wustl.edu /~ Schmidt/ace.html, where you can obtain the latest version of ACE and other related resources.
========================================================

Network Communication
Ace
Reference Site: http://www.c> http://www.cs.wustl.edu /~ Schmidt/ace.html
Representative of the C ++ library, a super-heavyweight network communication development framework. Ace adaptive communication environment (Adaptive Communication Environment) is an object-oriented framework that can be freely used and open source code. It implements many core modes for concurrent communication software. ACE provides a rich set of reusable C ++ wrapper facade and framework components to complete common communication software tasks across multiple platforms, including: multi-channel event separation and event processor allocation, signal processing, service initialization, inter-process communication, shared memory management, message routing, distributed service dynamic (heavy) configuration, concurrent execution and synchronization, and so on.
Streammodule
Reference Site: http://www.omnifarious.org/strmod/'> http://www.omnifarious.org/StrMod/
Designed to simplify the compilation of distributed programs. It makes it easier to write programs that process asynchronous behaviors, instead of using the synchronous shell to package the asynchronous nature.
Simplesocket
Reference website: http://home.hetnet.nl /~ Lcbokkers/simsock.htm
This class library makes it easier to write socket-based client/server programs.
A stream socket API for C ++
Reference: http://www.pcs.cnu.edu/'> http://www.pcs.cnu.edu /~ Dgame/sockets/socketsc ++/sockets.html
Another socket encapsulation library.

Http://blog.donews.com/dgsheng/archive/2006/03/16/771372.aspx

Ace modeled network programming so that you don't have to repeat the same code every time.

Network Programming involves interruptions, concurrency, and multithreading. The program format is relatively fixed, but robust network programs are relatively complicated. To handle these situations, Ace has several built-in network programming modes.

The most basic mode is, of course, a one-to-one model that uses sock directly for a single client, single server, and single thread. This mode is relatively simple and has little to do with Ace, however, a program written in this way cannot process concurrency, And the availability is poor or basically unavailable.

The simplest framework for processing concurrency but using a single thread is called the reactor framework in Ace. In this framework, the reactor plays the role of the Coordinator, the application creator needs to write a variety of Event Handlers first, and then register in the reactor. The reactor monitors all possible events simultaneously in blocking mode, the corresponding processing process is called when an event occurs. This framework solves concurrency on the premise of a single thread, but there are some problems. If the execution of an event is too long, it may cause the reactor to miss some events.

Another single-thread concurrent processing mode is called asynchronous I/O proactor mode. This mode is not much different from the reactor mode described earlier. The only difference is that, when the server class processes messages received from the network, the latter does not directly let the processor process the received messages, but first converts the messages into a Message Block Structure (ace_message_block, use this-> reader _. READ function), and then let the corresponding processing function process the received message block structure.

Compare the reactor framework with the proactor framework. The execution process of the former is: monitoring events-> calling event processing-> continuing to monitor events. The execution process of the latter is: monitoring events-> generating messages-> processing messages-> releasing messages-> continuing to monitor events. These two different frameworks, after introducing their respective multi-threaded concepts, will derive different multi-threaded frameworks.

As mentioned above, network programming using multithreading also has two frameworks: semi-synchronous/semi-asynchronous framework and leader/follower framework. The former corresponds to the proactor framework, and the latter corresponds to the reactor framework. In the so-called semi-synchronous or semi-asynchronous framework, the execution process is: the main thread is responsible for monitoring events-> generating messages-> putting them into the message queue-> monitoring events, the worker thread is responsible for obtaining another message from obtaining the message> processing the message> from the message queue. The advantage of this framework is that it is controllable to construct a message and put it into the message queue. Therefore, it can well handle network peaks, even if there is a high peak, there is no message omission, but because the message has an inbound queue and an outbound queue process, the performance is theoretically worse than that of another model.

The latter is a relatively more complex model. In the thread pool, only one thread is the leader thread, and the others are the followers thread. The leader thread monitors the event. When something happens, first, find another thread to become the leader, and then process the event. After the processing is complete, first try to become the leader again. If the attempt fails (the other thread has become the leader ), then you become a follower. This model is based on the reactor model and does not have the concept of message queue. Because there is no inbound/outbound queue process, the performance is better than the former theoretically. However, if there is a high network congestion, there may be no leader available and data loss because all threads are processing their respective events.

There is a thread pool in both multithreading models. In the semi-synchronous/semi-asynchronous model, a worker thread may be a worker thread pool. The synchronization of the Message Queue threads has been automatically completed by the ACE framework. Is there a job with more threads, the better? The answer is no. Multithreading can speed up customer response. For example, if two clients, A and B, initiate two requests one after another. If request a is completed for a long time, request B can be completed quickly. If there is only one working thread, then B needs to wait for request a to complete before receiving its own response. For a, it does not expect its request to be completed quickly. The actual execution will be, when a receives a response within the expected time, B uses a's time to receive its own response, and B's customer satisfaction will be poor.
If multithreading is used, a will delay a little bit to receive its own response, and B can also receive its own response within a reasonable period of time. However, due to the overhead of multithreading, the total time for a single worker thread to execute a and B is shorter than that for multiple worker threads to execute AB tasks.

For the leader/follower model, there must be a peer thread pool. The number of thread pools depends on the number of threads that the system can afford. For the model itself, the larger the number of threads in the thread pool, the larger the limit value of the network that can afford it. However, if the execution of each request takes a short time, there will be a large number of threads that will never be used in the system, wasting system resources.

If a multi-processor system is used, applications will inevitably be able to benefit from the multi-thread (working thread and followers thread) structure.