nerd1951.com

Usually when network element software is developed most of the initial work is focused on the data path. This is natural since there are performance issues, new hardware or new protocols to deal with and we want to prove that the data path works as early in the project as possible. We usually develop some simple command line functions to set up critical parameters for testing during this phase of development.

Once the basic operation of the network element is proven we start looking at the management functions. The command line interface developed in the first phase is enhanced to meet the needs of an end user. Then we may layer an SNMP agent and a web interface on top of the data path. This usually leads to an architecture similar to the one shown below:

There are several problems with this approach. First, there is usually duplicate code for each user interface. More code means more bugs, more debugging time, and less reliability. Second, the functions provided by the different user interfaces don’t always quite match up. Similar functions on the command line interface and the web interface for example do slightly different things, confusing the end user. Finally this architecture is difficult to maintain. The user interface often requires more feature changes and enhancements than any other part of a software system. Every time we need to add a new user interface function we have to modify the user interfaces and each of the data path components that are affected. This means more room for bugs to creep into the system. If you want to see a good example, look at how difficult it is to configure any out of the ordinary networking options on Linux or any other flavor of Unix. 

A better approach is to plan the architecture of the entire system early in the development. The Model-View-Controller architecture is ideal for this type of application. The Model-View-Controller architecture is often used by our colleagues in the web application business. The Model-View-Controller architecture applied to a network element software application is shown below: 

The critical point is that the model and controller provide an abstraction of the management functions of the data path. This allows the various views to see a single consistent interface. When a new user interface feature is required the data path is only modified once. The model and controller are simple to modify since they really just provide a façade (see the Gang of Four Design Patterns Book). Then the modifications to the various views are also quite simple since only user interface code needs to be modified. The views, i.e. the SNMP agent, Command Line Interface, and Web Interface can even be re-usable software components designed to interact with a predefined model-controller interface. Again, the less software you have to write, the fewer bugs and the better the quality of the product. And let’s not forget, quality products put more money in the bank. 

I’ve started a list of classes from the Standard C++ library and the Boost C++ Library that will be useful in implementing a network protocol stack. The list is on the C++ library classes page under Design Notes. In some cases I may use the policy classes from the Loki C++ library for more flexibility or write my own classes that implement interfaces defined in the Standard C++ library.

In other news, I’ve started writing the test code for various queue class implementations. The purpose is to assess if I can obtain any performance gains by writing specialized container class implementations using policy classes for specific locking policies: lock free, locked reader, locked writer, and double locked, as described on the FIFO Queue design notes page. My plan is to implement a specialized container class so that I can use the queue class interface specified in the Standard C++ library.

Those of you that read my blog regularly must have noticed that I’ve been offline for a few days. I’ve switched to a new web hosting service; one of the large well known services. While their service is not as flexible as what I had with a smaller firm, I’m sure that they will be more reliable. Plus they are a lot less expensive.

As my goals change for the Cannonball project change so does my approach. The goal is now to apply modern C++ design, i.e. generic programming and design patterns, to the problem of implementing networking protocols. So now my approach is to follow the time-honored approach of implementing a user-mode TCP/IP stack under a flavor of UNIX; Linux in this case. Then I’ll be able to use the Linux TCP/IP stack as a performance bench mark for measuring my modern C++ implementation’s performance.

In researching the standard C++ library and the Boost library, I am struck by the number of concepts used in the Linux networking architecture that map directly to concepts found in these C++ libraries. Writing a TCP/IP stack is an ambitious undertaking for a single person working on it part time but I believe that using modern C++ design techniques makes this possible to achieve.

I’m not making much progress on Cannonball right now between crunch time and preparing slides for the up coming Embedded Systems Conference but I thought it would be a good idea to report what I’m working on. As promised in an earlier post, I’m putting together an experiment. I’m going to measure the performance of queue implementations in the standard C++ library, probably the GNU version. Then I’m going to run the same test on my own queue implementations. If there isn’t a huge performance difference then I’ll just use the standard library queue and move on to the next problem.  I’ve been inspired to go down this path by an interview of Bjarne Stroustrup titled Abstraction and Efficiency.

The queue in the standard C++ library is actually just an interface to a container class.  The default container class for the queue is the deque.  The container class could be any sequence container class that provides the required interface functions.  I plan to experiment with different container classes and measure execution time and memory requirements.

The initial test will consist of one reader thread and one writer thread. Each time the writer thread executes it will push a random number of entries on to the queue. Each time the reader thread executes it will pop a random number of entries off of the queue. I’ll actually use pseudo random sequences so that the results will be comparable for the different queue implementations but I’ll use different seed values for the reader and writer threads. I’ll let this run a few thousand times and measure the average time to push and pop entries from the queue. Initially, I ‘ll run this experiment on my Linux box then find an embedded target to use that supports the C++ standard library and multi-threading.

C++ is actually an incredibly complex programming language.  In my thirty years of professional computer programming, C++ is the most complex language that I’ve ever used.  Sometimes I fell like I’m still becoming a C++ programmer.  One reason for this is that C++ is so powerful.  It gives you a wide variety of solutions for any given programming problem.  At the highest level C++ supports four different styles of programming:

• Procedural programming through it’s support of the C programming language
• Object oriented programming based on the C++ object model
• Meta-programming where types are used as parameters through C++ Templates
• Generic programming where programs are constructed using generic components as illustrated by the Standard Template Library

So this raises the question; “How does one become and expert C++ programmer?”  The only real answer is to write programs in C++ but this is not a single-project answer.  Becoming an expert C++ programmer takes dedication and patience.  Looking back on my experience with both the mistakes and successes that I’ve had here is the approach I would suggest:

• First, learn the C++ features that enhance procedural programming in C.  Learn to use static const to define constants instead of #defines.  Use inline functions instead of macros as much as possible and learn to use C++ style casts instead of C style casts.  This step is also a good time to start exploring the C++ standard library and to get in the habit of using the C++ libraries instead of the C standard libraries.  Try to do a large project this way.  Short of that, program all of your unit test code for a project using C++ style procedural programming.
• Second, learn object oriented programming.  I don’t believe that C++ is the best language for learning object oriented programming though some people do.  I took a couple of introductory computer science classes that were taught using Java at a local university then worked as a TA for a couple of semesters.  Becoming a good Java programmer made me a much better object oriented C++ programmer.
• Third, start using the STL and other libraries to gain an appreciation of what can be done using C++ Templates.  Start writing a few Template classes and functions of your own.  The source code for the STL, the Boost Library and the Loki library are all available online and are good examples of what can be accomplished using C++ Templates.  Though I’ve been a C++ programmer for over ten years and did consider myself an expert, I’m still relatively new to C++ Templates and I’m just learning about generic programming.

Bjarne Stroustrup wrote a paper, C++ Programming Styles and Libraries emphasizing the use of libraries and generic programming.  The paper mentions a number of books for educating yourself in modern C++ programming techniques and writing and using C++ libraries.

It’s been crunch time lately on my day job. So I’ve barely had the ambition to read anything lately, much less write anything worth reading. But it’s been so long I feel that I should try.

It’s a funny thing about crunch time. It always happens at some point in a project. Even the best planned projects I’ve ever worked on have had times when it took a heroic effort to meet some milestone.

Sometimes it’s just the complexity of the work we do. I’ve had bugs in systems where it took ten hours of work just understand all of the variables so I could find the problem. If I had given up after eight hours and gone home and got a good nights sleep, I would have just wasted eight hours of effort. In embedded systems sometimes it takes a few hours just to set up the conditions for the bug to occur.

But most times crunch time is the result of poor planning, bad specifications, rushing the design, or, much too often, not designing the software at all.

I’ve been reading Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu in my research of generic programming.  In his book, he emphasizes the use of Policy Classes as a technique for generic programming.  As Alexandrescu writes:

In brief, policy-based class design fosters assembling a class with complex behavior out of many little classes (called policies), each of which takes care of only one behavioral or structural aspect. As the name suggests, a policy establishes an interface pertaining to a specific issue. You can implement policies in various ways as long as you respect the policy interface.

Because you can mix and match policies, you can achieve a combinatorial set of behaviors by using a small core of elementary components.

The FIFO Queue that I’m designing seems like a good candidate for a Policy Class implementation.  If you look at the design notes page for the FIFO Queue you’ll see that there are two implementations of the queue itself; an array based queue with a bounded length and a list based queue with unbounded length.  In addition the read function may be lock-free or locked for serialized access to the queue head.  Likewise the queue write function may be lock-free or locked.  This seems like just the kind of “combinatorial set of behaviors” that Alexandrescu is talking about.

I’m starting to see some important characteristics for components for a Network Protocol C++ Library.  Among them, thread safety and minimizing context switching.  Unlike many other C++ libraries, these issues must be considered from the ground up in designing libraries for networking software.

I recently read an article that was critical of the whole concept of blogging.  The point of the article was that hundreds, perhaps thousands of people thought that they would become rich and famous by becoming a star blogger.  I don’t agree with the author.  I think that there are as many reasons for blogs as there are bloggers.

There are those who look to blogging as a way to cash-in.  You can recognize these sites by all the Google ads, banner ads and links to Amazon.com.  Some blogs are professional self-promotion.  The blogger is proving their professional credentials through their writing. The problem for many of these bloggers is that their audiences are very small.  Many might be writing to themselves.  This was the point of the article.

Others have more personal reasons for blogging.  There are blogs that are personal; aimed at a select group of family and friends.  Some bloggers write to share information about their hobbies.

My own blog is a hybrid.  It started as a way for me to write notes to myself actually.  I am an aspiring author and found the blog to be a comfortable medium for keeping a journal for my writing projects.  Then I found that a few people were actually reading what I wrote so I gave it a face-lift and added a bit of information about myself.  I’ve had old friends that have been out of touch for years find me through my blog.  When I was invited to speak at The Embedded Systems Conference, I decided a little self-promotion wouldn’t bother anyone.

I have a few regular readers now, maybe three or four.  I find that the comments and feedback that I get about my writing and projects to be the best part of blogging.  It’s difficult to find people who are interested enough in a technical specialty to read my stuff and give me feedback so I am very grateful to those of you who have left me comments.

Coming from a technical background I like to measure things.  For the longest time I had the feeling that I was writing to myself.  So I started using Google Analytics to track the number of visitors to my blog a couple of months ago.  The reality is that my blog gets between twenty-five and forty visits a week.  The average is about thirty-five visits a week.  There is no long term trend up or down at this point.  Many of these visitors I’m sure bump into my site from a web search and realize that it’s not what they were looking for and never return.  The long term trend that I have noticed is that the number of returning visitors has increased from about 30% of the visits to about 50% of the visits.

My plans are to continue to use this site primarily as a journal for my rough drafts.  So I’ll continue to document my personal research into C++ programming for network protocols, make observations about software development and computer networking, and throw in some geeky fun stuff once in a while.

But now that I know I have an audience and I value your feedback, I want to keep my blog interesting and relevant.  I’d like to hear from more of you.  Let me know if I get boring or start writing about useless stuff and especially if you disagree with what I have to say.  This way we can all learn something new together.