The learner is born and the learner is dead-ACE history and summary

Document directory

• 1. There are no monographs on ACE except for the three books written by Douglas Schmidt and Stephen Huston.
• 2. ACE is very difficult to use and is very easy to use with errors
• 3. ACE code quality is not high. It is more like a research project than an industrial product.
• 5. ACE is too complex, or even more complex than the objects it tries to encapsulate.

ACE is the originator of modern object-oriented network programming and has established many important models, such as Reactor and Acceptor. It is important that we even think network programming should be like that. But why does ACE not call a seat? But few users are famous? This article will talk about my personal points of view.

ACE is a heavyweight C ++ network library, which was developed independently by Douglas Schmidt in earlier versions. More than 40 students and staff also contributed a lot of code. Author Douglas Schmidt has published more than 30 academic papers. One of the major features of ACE is that it integrates many design patterns of object-oriented network programming proposed by Douglas Schmidt and has incredible cross-platform capabilities.

1. ACE history

Let's talk about the personal experience of Douglas Schmidt, father of ACE:

• In 1990, he obtained a master's degree in computer science from the University of California Irvine;
• In 1994, he obtained a doctorate degree in computer science from the same school. His thesis is "An Object-Oriented Framework for Experimenting with Alternative Process ubuntures for Parallelizing Communication Subsystems". From the content of this paper, the main work is the later well-known ACE framework, which is called ASX framework.
• After graduating from the University of Washington in 1994, he served as an Assistant Professor and then promoted to an associate professor.
• Since 2003, Professor Ren Zheng has been at the vandbilt University.

I believe that ACE is the primary role of Douglas during his studies at his blog. The name of ACE first appeared in a conference paper in December 1993. This article of Douglas won the "best student thesis" award. Prior to this, Douglas had published articles with similar content using other names such as ASX.

The earliest ACE version that I can download is 4.0.32, which contains about 86,000 lines of C ++ Code. The Code timestamp is January 1, October 22, 1998. ACE was developed independently by Douglas Schmidt in the early days. It was learned from ChangeLog that the ACE version was November 1993 in 2.12. Only in September 1995 did other developers appear for the first time. In 1993 ~ During the 1996 changes in 684, Douglas contributed 529 times, and several other major developers and their modifications were Prashant Jain (58) and Tim Harrison (42), David Levine (28), Irfan Pyarali (20), Jesper S. M | roller (5 ).

From the perspective of ChangeLog, there were more than 1993 changes from March 2010 to 19,000. More than 200 people have modified the code, 23 of them have checked-in more than 100, and the top 12 of the Code revised are:

3635 Johnny Willemsen (active year: 2001 ~ Today)

2586 Douglas C. Schmidt (original author, active year: 1993 ~ Today)

1861 Steve Huston (active year: 1997 ~ Today)

1197 David L. Levine (active year: 1996 ~ 2000)

962 Nanbor Wang (active year: 1998 ~ 2003)

907 Ossama Othman (active year: 1999 ~ 2005)

865 Chad Elliott (active year: 2000 ~ Today)

823 Bala Natarajan (active year: 1999 ~ 2004)

708 Carlos o' Ryan (active year: 1997 ~ 2001)

544 J. T. Conklin (active year: 2004 ~ 2008)

479 Irfan Pyarali (active year: 1996 ~ 2003)

368 Darrell Brunsch (active year: 1997 ~ 2001)

What is your first response when you see these "active years? I think, will most of these people be graduate students guided by Douglas? I guess they are involved in improving ACE during their studies, writing their work into papers and publishing them, and then they graduate and leave. This may explain the diversity of ACE code styles.

During the process of browsing the code history, I also found a very interesting phenomenon. In March 4, 2008, someone accidentally deleted the entire ACE source code tree:

Https://svn.dre.vanderbilt.edu/viewvc/Middleware? View = revision & revision = 80824

Then the recovery was very fast:

Https://svn.dre.vanderbilt.edu/viewvc/Middleware? View = revision & revision = 80826

The guy who is doing this is 2005 ~ 2009 in the past few years, a total of more than 120 checks have been performed. What do you think about this? Is there such a person in your development team?

2. Facts and Thinking 1. There are no monographs on ACE except the three books written by Douglas Schmidt and Stephen Huston.

ACE is so easy to use that it does not need to be explained in other books. Is it too difficult to use it? Or no one cares?

C ++ network programming 1st, C ++ network programming 2nd, and ACE programmer's guide were published in 2001, 2002, and 2003 respectively, without any further updates. At the same time, in the network programming field, even though W. Richard Steven s died in 1999, his UNP and APUE were updated by others. The C-language Sockets API books are constantly updated, and the C ++ encapsulated in the upper layer is indifferent? Is it true that the package is in place to block these changes?

UNP is highly operable. After reading the previous chapters, you can get started with writing simple network programs. After reading more than half of the books, you can get started with network programming and write network programs for general applications. On the contrary, after reading the ACE books, I still feel unable to start with simple network programming tasks. Is this because of poor writing or the fact that ACE itself is not easy to use?

2. ACE is very difficult to use and is very easy to use with errors

I heard more than one person tell me that they tried ACE in the project, instead of giving up halfway, because the problem could not be solved; that is, they barely handed in the gap and never needed it from the next project. Another argument I have heard is that the examples of the ACE tutorial must be copied without any modification. Unfortunately, the example of ACE is a Logging server, which is hard to figure out. In the latest book "The beauty of code", Douglas Schmidt once again took it as an example to show that he really liked this example.

Using ACE programming is like a thin ice, for fear of turning the ship in the gutter, I don't know what tricks It is playing behind. On the contrary, using 10 Sockets system calls can handle network programming, and I feel less difficult than using ACE. Why are "advanced" tools not easy to use?

The direct consequence of poor use is that few people use ACE as a communication platform (I only know Mangos ). On the contrary, libevent, a lightweight IO multiplexing Library, has famous users such as memcached.

3. ACE code quality is not high. It is more like a research project than an industrial product.

Reading the current ACE code is like the code written by an intern. Aside from coding style, here are three "severe injuries ":

• Sleep <2 ms

In some early Linux kernels, if the select/poll wait time is less than 2 ms, busy-waiting is used in the kernel. This is a huge waste of CPU resources, and ACE does not seem to consider avoiding this.

• Linux TCP self-connection

The TCP implementation of Linux has a special "behavior" that initiates a self-connection in some special circumstances. The maintainer of the Linux network protocol stack thinks this is a feature, not a bug, and refuses to fix it. Generally, network applications do not want this to happen. The good Network Libraries I have seen will consciously check and disconnect this connection, but ACE does not care.

• Timeval on 64-bit

The ACE_Time_Value class uses struct timeval as the member variable and stores the number of microseconds starting from Epoch. This is okay in 32-bit. The object size is 8 bytes. On the LP64-bit platform, such as Linux, the object size is changed to 16 bytes, which is not enough. We can directly use int64_t to save the time in microseconds. The 64-bit integer can be saved for up to 0.3 million years, which is enough. Reducing the object size is not to save several bytes of memory, but to facilitate the transmission of function parameters. On the x86-64, this 8-byte struct can be passed directly using 64-bit registers, that is, pass by value will be faster than pass by reference. For general applications, whether or not to do so is debatable. For the underlying C ++ network library, the use of pass by reference without partitioning may cause the author to wonder why.

I suspect that ACE has never been used in a Linux mass production environment. I can only expect it to be better on other platforms. The authors of ACE seem to be more focused on verifying new ideas, and then sending papers, rather than putting them into the industrial environment for repeated tempering, to create a reliable product. (Similar to the relationship between Minix and Linux .)

4. Good portability, supporting many platforms I know and do not know

The significance of ACE is to let us understand how C ++ code can be transplanted and how costly it will be. I will not elaborate on it. Anyone who has read the ACE code will understand it.

From the perspective of code quality, ACE can run on these platforms, but it does not seem to be dominant in any platform. Which platform is ACE preferred for network programming?

The reason for this is that cross-platform and high performance are in conflict. Cross-platform means to abstract the commonalities of multiple platforms and write the upper-layer code in the most general way. However, high performance requires that the features of the platform be fully utilized, and the platform can be used up to accelerate all the methods provided by the platform, even if it is not compatible with other platforms. Network Programming is especially sensitive.

I don't know the performance of ACE, because the name of ACE is basically not displayed on the Performance Evaluation List (there is no ACE in c10k ). In addition, the quality of the Buffer class directly reflects the performance pursuit of the network library. Does ACE provide a better input/output Buffer than std: deque <uint8_t>? (I'm not saying how good deque is. It is basically the choice of fail-safe .)

5. ACE is too complex, or even more complex than the objects it tries to encapsulate.

(The number of lines of code here is a rough estimate of the wc command .)

ACE 5.7 itself (excluding TAO and CIAO) has 0.3 million lines of C ++ Code (the data provided by Douglas itself is 0.25 million rows, which may refer to earlier versions ), what is this concept? Let's take a look at how many lines are implemented by the TCP/IP protocol stack itself: (IPv6 is not included)

• The complete TCP/IP protocol stack code of BSD4.4-Lite listed in TCPv2 contains 15,000 lines, including 4,500 lines of TCP protocol, 800 lines of UDP protocol, and 2,500 lines of IP protocol
• Linux 1.2.13 complete TCP/IP protocol stack has over 20 thousand lines (net/inet)
• Linux 2.6.32.9 TCP/IP protocol stack has over 60 thousand lines (net/ipv4)
• FreeBSD 8.0's TCP/IP protocol stack has over 50 thousand lines (sys/netinet, excluding sctp)

In other words, ACE uses 0.3 million lines of C ++ code to "encapsulate" less than 0.1 million lines of C code (regardless of whether the information density of C ++ code is higher than that of C). Is this a top priority? What I understand as "encapsulation" is to make complicated things simple, but ACE seems to go in another direction and make less complex things more complicated.

This comparison number may not be accurate, because ACE also encapsulates many other things. Please refer. Http://www.dre.vanderbilt.edu/Doxygen/5.7.7/html/ace/inherits.html and http://www.dre.vanderbilt.edu/Doxygen/5.7.7/html/ace/hierarchy.html

The inheritance relationship of the following two classes is displayed in a new window:

Http://www.dre.vanderbilt.edu/Doxygen/5.7.7/html/ace/a06178.png

Http://www.dre.vanderbilt.edu/Doxygen/5.7.7/html/ace/a06347.png

Douglas said ACE had a 40-person-year workload and I had no doubt about it. But does network programming really need to be so complicated? The implementation of the TCP/IP protocol stack does not work that much. Maybe only applications like CORBA can use such complicated things? So why is ACE not used by ICE to implement CORBA again? Is it because the ACE shelf is so big that the bottom is not strong?

3. Significance of ACE

ACE has a great history and practical significance for object-oriented, design patterns, and network programming.

When ACE was born, it was the rapid development of object-oriented technology in the early 1990s S. ACE was promoted to a certain extent as a successful case of object-oriented technology.

Around 1994, Unix was divided into two camps. AT&T's SVR4 and BSD's BSD4.x were not fully compatible with their IO multiplexing. For example, SVR4 provides poll calls, while BSD provides select calls. One of ACE's publicity points at that time was to use object-oriented technology to shield the differences between the two platforms and provide a unified Reactor interface.

[Next, poll joined NetBSD in September 7, 1996 and was released in 1.3 with NetBSD January 4, 1998. FreeBSD 3.0 also supported poll, which was released in October 1998. Linux has long supported the select statement. Since kernel 2.1.23, poll is supported. The release date is January 1, January 26, 1997. That is to say, by 1998, the platform differences were temporarily flattened. Later, epoll,/dev/poll, and kqueue expanded the platform differences again in the name of performance. Of course, Windows does not support poll so far .]

The ACE design seems to emphasize the object-oriented flexibility too much. Some places that should not use virtual functions also provide customization points. For example, ACE_Timer_Queue should be a specific class, instead of allowing specific operations such as override schedule/cancel/expire. In object-oriented systems, the purpose of "inheritance" is to be reused, rather than reusing the code of the base class.

The Reactor published the "C ++ Report" magazine in 1993. The title of the article is still simple and the banner of "Object-Oriented" is hanging:

• The Reactor: An Object-Oriented Interface for Event-Driven unix I/O Multiplexing (Part 1 of 2)
• The Object-Oriented Design and Implementation of the Reactor: a c ++ Wrapper for unix I/O Multiplexing (Part 2 of 2)

In the twinkling of an eye, in 1994, that is, the year when the design pattern was written, Douglas began to write an article, which must be called pattern:

• The Reactor becomes pattern, which is included in the book "Pattern types of Program Design" (An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events ). This article is more difficult than the previous two articles. If you want to read it directly.
• Acceptor is pattern (A Design Pattern for Passively Initializing Network Services ),
• Connector is also pattern (A Design Pattern for Actively Initializing Network Services ),
• Proactor or pattern (An Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Asynchronous Events ),
• Even Thread-Specific Storage becomes pattern (An Object Behavioral Pattern for Accessing per-Thread State Efficiently ).
• There is also Non-blocking Buffered I/O, which is also pattern (An Object Behavioral Pattern for Communication Gateways ).

It seems that the word "pattern" has become a pass for the article, and this ethos will not stop until around 2000. These papers were published later, and several books were published in the name of Pattern-Oriented Software Architecture. The contents of ACE were mainly concentrated in the second volume. (Please note that the original concept is Object-Oriented, which is now Pattern-Oriented. It seems that software development should be like a candy factory producing green bean cakes and printing them one by one using a model .)

ACE is like a pattern field. It is conservatively estimated that there are 10 patterns hiding in it, forming a set of Pattern languages (Applying a pattern Language to Develop Application-level Gateways). this does not include the OO pattern defined by GoF in the general sense.

Using ACE to learn network programming means putting the cart before the horse, because it cannot teach you any knowledge other than UNP. (Windows Network Programming ?)

However, if network programming is to be implemented in an object-oriented way, ACE's idea (rather than Code) is worth following. After all, it is full of the painstaking efforts and wisdom of scholars such as Douglas Schmidt. Examples of learning well include Apache Mina, JBoss Netty, Python Twisted, and Perl POE.

This is what I mean by saying "the learner is born, the one who uses it is dead.

4. ACE literature Guidance

Douglas Schmidt has written many ACE articles, many of which contain similar works. To read his articles, he preferred to post articles in technical journals (such as C ++ reports), rather than papers published in academic journals or conferences. The purpose of the former is to teach readers technology, while the latter is often to show the author's new ideas and new ideas. Technical Articles are much better to read than academic papers.

At that time, the object-oriented technology was still developing, and the figures in the Douglas article were quite distinctive, rather than the standardized UML diagram (which was not finalized yet ), instead, it is a class chart like a deformation insect (which was invented by Grady Booch, as pinxue points out), which is easily recognized in a pile of documents.

If you want to use the ACE code to verify the idea of the article, I suggest you read the 4.0 version code in the same period as the article. The Code style is uniform and the amount of code is not large, which is easy to understand.

The following describes several representative papers.

• The ADAPTIVE Communication Environment: Object-Oriented Network Programming Components for Developing Client/Server Applications received The best essay Award at The December 1993 SUG conference in 11th. This is the first paper I found with ACE as the subject.
• The ADAPTIVE Communication Environment: An Object-Oriented Network Programming Toolkit for Developing Communication Software received The best essay Award at The June 1994 SUG conference in 12th.

In fact, the content of the above two articles is basically the same, which is an overview of ACE. Just read the second article. It doesn't matter if you didn't understand it for the first time.

The rest is about Socket OO encapsulation, four Reactor, three Acceptor-Connector, and one Proactor. Most of these articles have previously been linked, and the rest will be added here:

• IPC_SAP: A Family of Object-Oriented Interfaces for Local and Remote Interprocess Communication
• The Design and Use of the ACE Reactor
• Acceptor and Connector -- A Family of Object Creational Patterns for Initializing Communication Services, because it only combines the previous two articles published in C ++ Report.

If you don't want to read these 10 papers, read the Chinese translation C ++ network programming 1st, C ++ network programming 2nd, ACE programmer guide, the translation quality is good.

5. C ++ network library

It has nothing to do with the subject of the article.

I think the network library should solve practical problems and meet actual needs, rather than heap features/patterns there for others to use. There should be an application first, and then extract the database. Instead of creating a database first and then looking for an application.

Chen Shuo (giantchen_AT_gmail)

Blog.csdn.net/Solstice

2010 March 10

From: http://blog.csdn.net/Solstice/archive/2010/03/10/5364096.aspx