2007 Sep 14 - Fri

Software Development, Coders, and C++ Libraries

I grew up with Assembler, Pascal, then C, then C++, then C#, and now I'm back to C++. I've found that C# makes things easier for graphical programming, but it feels sluggish when doing some computationally intensive things. I've since moved back to C++. Development time has increased on some stuff, but I think things are better, and I derive more pleasure from C++ development. And C++ has a rich heritage and a rich library universe. This entry goes through some interesting things I've found.

One of the first libraries I came across was the Boost Libraries. I believe I've written about these before. A few specifics of interest include Regular Expressions, a soon to be released Time Series, date/time operations, some geometry constructs, state machine tools, and, well, the list goes on.

A few days ago, in looking for sophisticated Web Application tool kit. Wt: a C++ Web Toolkit appears to fit that niche very well. It also handles Ajax like functionality.

To assist with web development and layout, Firebug: A Firefox Addon might be of value for page layout issues. Although it has nothing to do with C++, which is the main topic here, it does have to do with finding a viable solution for checking out web page design.

Earlier today, I came across dzone: fresh links for developers. It has a wealth of links to articles written by developers for developers, developers of all categories and skill sets. Doing a search on C++ comes up with quite a list of articles.

One of the links pointed to The Programmicon. This article is mostly game based, but gaming shares cross-functionality with many disciplines. This once had two links to resources regarding finance. I was first introduced to Multivariate Embedding Methods by Carol Alexander on page 405 of her book Market Models. Although she won a prize for best price predictor using a model with that concept, I havn't been completely sold on it's applicability. If I had time I'd try it out. However, a key part of embedding is nearest neighbor analysis. The Programmicon points to a site providing ANN: A Library for Approximate Nearest Neighbor Searching. It also points to TMV - Template Matrix/Vector Library for C++, something else upon which embedding algorithms are built. Embeddings are based upon chaos theory. The concept is to try to find self-similarity in continous time. When similarities are found, you've got a predictor. Easier to say than do.

dzone also re-introduced me to LUA: An Embedded Programming Language. Debian Administration discusses how to incorporate it in to C++. I'm thinking it might be useful for scripting signals in a network monitoring package or defining charts in a financial modelling solution, or performing information searches in text analysis tools, or performing event & signal handling in a Cricket grapher.cgi rewrite. IEEE Software has an 8 page article called Traveling Light, the Lua Way. Kind of related is Kepler: Lua based web development platform.

During a brief flirtation with Fuzzy Logic, where one needs to evalute line crossings and area calcuations, I realized Computational Geometry might be of use. The C++ library Wykobi might be of value for optimized algorithms. The Code Project discusses its use.

I'm currently 'enjoying' MFC based development. I'm wondering if, since I'm still at a relatively early stage, I should be using TrollTech's Qt: Cross-Platform Rich Client Development Framework.

From a Microsoft perspective, Somasegar's Weblog has an article on 'Visual C++ Futures'. There are more than 200 user comments summing up needs, wants, and desires in that universe.

[/Trading/AutomatedTrading] permanent link

IP Addressing Best Practices (plus VRF and VLAN ideas)

I've encountered many weird and wonderful IP Addressing schemes during my consulting engagements. During my early years, I'm sure I've contributed some less than optimal ideas into the mix. I'm going to try to mend my ways and introduce some ideas that I think make things better.

Since the advent of Network Address Translation, network designers/architects/engineers have three basic address ranges from which to choose. These address ranges are based upon what is known as RFC 1918 - Address Allocation for Private Internets. The three ranges are:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

These are, what some call non-routable addresses. To be more specific, routers routing public addresses, will typically drop (not route) packets having destination addresses from these ranges. Of course, private networks are free to route these addressess as they see fit.

The commentary below assumes a basic knowledge of ip addressing, subnet allocation, host addressing, and routing.

When starting with small networks, a network installer may simply choose some random /24 block from one of the three ranges, and start assigning addresses to all devices on the network to that block. When installing IP Phones, some similar rationale may be used to pick some onother block for the phones. Some rationales that I've see included:

• let's choose 10.20.10.x for workstations and 10.20.20.x for phones, it keeps them in a similar big block, and keeps the octents nice workable numbers
• let's choose 10.20.30.x for workstations and 192.168.30.x for phones, it keeps them separate and identifiable, but yet similar in one octet
• let's add 172.20.30.x as a network management block as it is something completely different and identifiable as being not normal traffic

I'm sure you can come up with many other mechanisms. But what happens when you want to get another office joined in? Then suddenly one has a bunch of different blocks one has to add into a routing table. The lazy answer would be to simply use a statement like 'network 10.0.0.0'. There. All routes for that block are automatically known and added into the routing table (syntax and concept varies a bit depending upon which routing protocol you use).

I'm not sure if that is an optimal solution. I generally like to be very specific about which subnets or supernets I allow into a network table. With addressing scattered through three different address ranges, detailed route table maintenance becomes time consuming.

I like to use route aggregation whenever possible.

I left that statement by itself as it is a very powerful statement. It is also a strong, guiding principle in network/routing table design.

I've used that to come up with a hierarchical addressing structure that works with many of my client sites. There are some scalability issues for very large organizations with many large offices. For the majority of organizations, I think the following scheme works well. As I'm in Bermuda, Bermuda is the center of my universe, and the numbering is based partially on that concept. There is nothing saying you can't change things to match your own geographic realities.

Since the 10/8 address range has the most number of addresses to work with, I use that as a basis for most schemes. The hiearchy I use follows this pattern. I'll break the last three octets into a bit map and assign meanings:

octet bitmap:
00001010.wwwxxxxx.yyyyzzzz.00000000

bitmap meanings:
www:   region (NA (001), SA (010), Europe (011), PacRim (101), Asia (100)
xxxxx: country [ BM 1, CA 2, US 3, UK 1, IR 2 ]
yyyy:  city [ HAM,BM 1; NY,US 1; PA,US 2 ]
zzzz:  VLAN 

The region numberse, starting at 1, are loosley based upon contintents and how inter-country fibres are run. These categories help with aggregation. Within a region, countries are numbered, starting at 1. Within a country, cities are numbered starting at 1. I start the numbering for each bit section at 1, as I use the 000, 00000, and 0000 portions for addressing of inter-region, inter-country, and inter-city links. You can't really aggregate those addresses into the routes of either site, so they need to be kept separate.

Therefore, for a site in Hamilton, Bermuda, addressing would start at 10.33.16.0. Addresses from the range 10.33.0.0 to 10.33.15.255 would be used for inter-city links. Addresses from 10.32.0.0 to 10.32.255.255 would be used for inter country links. Addresses from 10.0.0.0 to 10.31.255.255 would be used for inter-region links. Ip address utilization in this range is acknowledged to be quite sparse.

You'll note that this scheme breaks when you have coverage in more than 15 cities. Therefor the scheme needs to be adjusted based upon how many locations you have, how many buildings in each location, and how many floors in each location. It doesn't matter how the bit map is structured, just so long as some rule for aggregation is followed as the level of aggregation grows.

At each site, I've been refining a strategy for vlan and ip address block assignments. Sixteen is a base(2) number, and therefore easy to aggregate. I assign 16 /24 blocks and 16 VLANs per site using a strategy similar to:

+0	Subnets for /30 links
+1	Servers
+2	Server ILO Ports
+3	SAN, iSCSI Traffic
+4	Voice Servers & Gateways
+5	Lab/Classroom/Testing
+6	Spare, To Be Assigned
+7	DMZ
+8	Workstations
+9	Phones
+10	Wireless Corporate
+11	Wireless Phones
+12	Wireless Guest
+13	Wired Guest
+14	Printers
+15	Network Management

The first set of eight blocks are server related. The second block of eight are client related. If an organization has mulitiple floors, conceivably a sequential block of eight would be assigned to each additional floor.

For VLAN numbering, I have a couple of different schemes. One scheme starts at VLAN 100 and assigns vlans 100 through 115 to each /24.

A second scheme is more complicated. In some locations, I use VRF's to segragate and route traffic. VRF's are handy when you have guest traffic you want to keep separate from corporate traffic. Cisco has a number of SRND documents on how this is accomplished. Anyway, I've used up to 5 segragations: 1 global routing table plus four VRF's:

1XX	global		100
2XX	vrfExterior	200
3XX	vrfData		300
4XX	vrfVoice	400
5XX	vrfGuest	500

The first column is are the VLAN identifying numbers, the second is the VRF name, and the third column is the OSPF process number. By adding this numbering scheme to the VLAN types previously provided, the following table might be used, where column 1 is the VLAN ID, column 2 is a relative offset of a sequential VLAN numbering system, and the third column is the description:

	+0	Subnets for /30 links
301	+1	Servers
302	+2	Server ILO Ports
303	+3	SAN, iSCSI Traffic
304	+4	Voice Servers & Gateways
305	+5	Lab/Classroom/Testing
	+6	To Be Assigned
	+7	DMZ
308	+8	Workstations
309	+9	Phones
310	+10	Wireless Corporate
311	+11	Wireless Phones
512	+12	Wireless Guest
513	+13	Wired Guest
314	+14	Printers
115	+15	Network Management

Some don't have VLANs as they don't exist as VLANS, but are address ranges uses elsewhere at the site.

Here are some additional VLAN assignments I'll use:

• 1: turned off, or not used at all
• 2: trunk native VLAN
• 3: 802.1x unauhtorized clients
• 20 - 29: switch SPAN ports for various monitoring activities
• 299: vrfExterior router to firewall exterior
• 399: vrfInterior router to firewall interior
• 599: vrfGuest router to firewall interior

Here is a finished table for showing address assignments for two different locations:

VLAN	Offset	BM Office	NY Office	
	+0	10.33.16.0	10.35.16.0	Subnets for /30 links and loopbacks
301	+1	10.33.17.0	10.35.17.0	Servers
302	+2	10.33.18.0	10.35.18.0	Server ILO Ports
303	+3	10.33.19.0	10.35.19.0	SAN, iSCSI Traffic
304	+4	10.33.20.0	10.35.20.0	Voice Servers & Gateways
305	+5	10.33.21.0	10.35.21.0	Lab/Classroom/Testing
	+6	10.33.22.0	10.35.22.0	To Be Assigned
	+7	10.33.23.0	10.35.23.0	DMZ
308	+8	10.33.24.0	10.35.24.0	Workstations
309	+9	10.33.25.0	10.35.25.0	Phones
310	+10	10.33.26.0	10.35.26.0	Wireless Corporate
311	+11	10.33.27.0	10.35.27.0	Wireless Phones
512	+12	10.33.28.0	10.35.28.0	Wireless Guest
513	+13	10.33.29.0	10.35.29.0	Wired Guest
314	+14	10.33.30.0	10.35.30.0	Printers
115	+15	10.33.31.0	10.35.31.0	Network Management
				
		Default Gateway is x.x.x.254		

This type of scheme, when implemented from the start, provides easy expansion of an organization's network, provides an ability to add protections between network devices, and simplifies inter-site routing.

[/OpenSource/Debian/AddressManagement] permanent link

LightFactory for Lighting BMDS' Production of The Sisterhood

It was an interesting experience, to say the least, in terms of being a first time lead lighting designer, introducing new equipment to the theatre, and learning a new piece of software.

All in all, the time was well spent. Live cue updates during rehearsals were simplified through a logical layout of lighting instruments in LightFactory.

In the diagram, instruments are assigned positions based upon the area they illuminate rather than the location they occupy in the grid. As such, in the diagram, there are five groups of four instruments. The top one of the diamond is a down light, the left was an amber 'warm' wash light, the right was a blue 'cold' wash, and the bottom was a lavender wash for the dark skinned actor, (the remainder of the cast were light skinned).

The channel over each of the four ColorCommand lights controlled the intensity. Each ColorCommand had three colors (magenta, yellow, and cyan), plus a beam width control.

Some of the specials were: 35: the bar bottle highlight, 32: a spot for a solo cast member talking to the audience, 19: a red downlight for the lovers, 2: the greenish downlight on the phone, 17,23: plant decoration, and 48: audience lights for intermission.

Over five acts, there were a total of 44 cues for the show, including one for doing a 15% on all lights for a lamp test.

The biggest hassle with LightFactory was in using the color lights. It took some time to work around some issues of assigning colors to a group of color lights. I think this has now been fixed. From what I see in the bug reports, there were some fixes implemented for refreshing Channel Groups and Palettes in a more timely fashion. I thought about updating the software once the bugs were fixed, but decided to run the software as it was through the show: better an enemy you know than one you don't. I'll update the software for the next show.

[/Personal/Lighting] permanent link