The Android OS is out for quite some time. Recently it was decided that we should bring our SIP Stack revolution to this uncharted world It was a challenging task, which only a few can take: .  a new operating system, to add to the many that our stack already works with. I boldly took the responsibility on myself, and I emerged triumphant. Well, kinda.

The First Hesitant Step

The heavy-duty work was done by our Common Core team. They are the experts in porting our OS-abstraction layer APIs to work with new operating systems. This layer helps us, the rest of the developers, to work without directly interacting with the OS bits and bytes, pipes and ports and whatnot. So what’s the big deal in another OS to port to, right? All you have to do is RTFM. Such an easy job those Common Core people have….

Therefore, after this “unimportant” phase, it was time for me to work my magic. Of course, with the help of our Common Core team, again. Why? Because the Android’s way of compiling code is quite different than the one we usually use. The first thing I had to do is check out the documentation of the Android’s Makefile system. It was buried deep in the NDK documentation (<NDK_INST_DIR>/docs). That took me some time. Or at least that’s what I told my boss when asked about my slow progress.

We’re On It, Baby

So we were done with the porting, and we knew how to name the android Makefile (android.mk – Ingenious!). Our system started humming and making start-up sounds. Now came the hard part: should we force Android developers, our existing and new customers, to work our way (and as god intended, if I may say), or submit ourselves to Google’s will?

The thing is – if you wish to compile your code, you need to place it under one of the Android NDK folders. You can’t just place your code anywhere you want, as you used to with *nix or Windows. You must have at least one anchor well placed under the environment tree. Out of generosity, we decided to let Google win this time.

After some additional steps (write a JNI wrapper, place an Android.mk file in almost every folder, etc.), we were able to compile everything. Experts as we are, it all ran smoothly the first time we tested it. That is, if you agree to call that time we tried it, after 3 weeks of continuous debugging because of crashes, the “first time”. But what are 3 weeks compared to eternity, right?

So What You Should Do

If you’re going to develop some code under the Android platform, there are some things you should know. First, you’ll need to download and install the Android SDK and NDK. You should also write some pieces of JNI code that will connect the Android GUI to the C code you’re writing. It will also be a good idea to download and install Eclipse, and then install Android ADT plug-in for Eclipse. For more information, you might want to read this article.

Conclusions

It was a nice experience. People actually thought I work on Android (I didn’t. Remember the OS-abstraction layer?) and I could see them gather in the corridors, whispering about the cool job I have. Hey, if they are already staring at me, I rather think this is what they’re thinking.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• Visual Studio 2005 And Beyond (0)
• Integrity Porting (0)
• About The Intel Threading Tools, Our SIP Stack, and Me (0)
• Software Is the New Hardware (2)
• SIP Multicore optimization – the aftershock (2)

As mentioned in one of my previous posts, we do have customers. Some of those customers do have special needs (don’t they all?). Lately, one of our customers asked us to update our workspaces, so that they can use our product with Microsoft’s Visual Studio 2008.

The Whole IDEa

Up until now, we had two types of solutions for the Windows platform flavor of our toolkit: the “legacy” Visual Studio 6.0 (or VC6) .dsw files, and the Visual Studio 2005 (or VS2005) .sln files. That was OK, because we actually had to support only one type. After all, who else but us still uses Visual Studio 6.0? But we liked it: the IDE was clear, menus were fine, Visual Assist supported it — We were happy. In fact, most of our development was done using this IDE version, while Visual Studio 2005 was used mainly for testing before releasing new stack versions for those of you out there, the adventurer types, who call a 2-years-old technology “new”.

The New Found Problem

We have many customers. It’s a problem. We want to support them all. It’s even a bigger problem. If they want to work with VC6, we should have a solution for that. And if they want to work with VS2005, we should also support that.

From file-tree perspective, we need to support these two options at the same time. We also have to support Unix and Linux flavors, as well as other embedded operating systems, but that’s a different story.

Back then, when we added support for VS2005, life was easy. VC6 had .dsw and .dsp files, and VS2005 had the matching .sln and .vcproj files. Two different set of files, unique extensions. But how do you support two versions of the IDE that have the same file extensions?

You see, with Visual Studio 2008 (VS2008), Microsoft didn’t change the file extensions. You have the same .sln and .vcproj files as in VS2005. The contents are different, but the extensions are the same. We needed to differentiate them somehow, but not work too hard on maintaining those 2 sets.

And it gets worse: If you try to open a VS2005 .sln file in VS2008, it will automatically convert it and all of its contained .vcproj files to VS2008 format. If you then try to re-open them in VS2005, Visual Studio will tell you that you can’t:

Why? Because they can. A possible solution for this may be to put the VS2008 .sln files in a different folder than the VS2005, but our customers are already used to finding our .sln files and Makefiles (for non-Windows OS) in the same folder. We can use 2 different sets of files, but we will have to maintain them, which is time-consuming. And we also had to think of the future – after all, VS2010 is coming, and the VS train doesn’t stop there. The horror…

This was frustrating, really. I get that some general information about your project should be aggregated in some file: dependencies, project settings and such. But what crucial information should be saved there, that needs to be different between versions? How come no one thinks of me, the programmer, at the end of the fool chain, who needs to support (at least) 2 Visual Studio IDEs in parallel?

The Easy Solution is Always Worth a Shot

Yes, we eventually decided not to support that customer, and asked him to contact our competitor. Hopefully, no other customer will have such a ridiculous request.

Well. Not really. Our PM didn’t really agree to that solution.

Alternate Ending: A Real Solution

My bosses in Radvision have foreseen the future, and sent me to a Perl course a while ago. Seeing that it was good, they said “let’s send him to another course. Maybe cooking. With enough courses, the solution will eventually present itself”. I didn’t object, of course, but the budget controller did. So it was just Perl.

We decided that all of our engineers will start working with VS2008 when developing. And we will maintain 2 sets of .sln/.vcproj files: VS2008 files will have the suffix “_vs2008″ added to them; VS2010 files will have the suffix “_vs2010″. And VS2012 files? We’re just programmers. We’ll have to wait for the PM to decide what suffix to use there.

And, we will write two Perl scripts:

The first will be used once, to duplicate all our .sln/.vcproj files while concatenating their copies with the new suffix to their names. The script will also update the internals of the .sln files to use the new project file names. We have dozens of .vcproj files, so an automatic operation of a script is required. Once done, the rest will be magically completed by the upgrade wizard of VS2008. We’re even making this wonderful script available to you, if you think it might assist you. Just follow this link.

The second script will be used to downgrade the VS2008 files to VS2005 files before releasing new versions to customers. So we will need to maintain two (more in the future) sets of VS files, but scripts will be used to do the editing tasks (removing new attributes added to new .sln files , altering .vcproj files, etc.), and all we will need to do is to just check that everything is compiling and running at the end.

And voila —

Before	After

Conclusions

Here’s my 2 cents (hey, there’s a recession going on!):

• When developing a system, think about the future as well. In the VS case, I don’t see any reason why VS2005 shouldn’t open VS2008 .sln files, chew up everything it can, and drop everything it doesn’t understand.
• On the bright side, XML is a good option when considering making a configuration file, as in the case of .sln and .vcproj files. A simple scripting language can then greatly help when deciding to do some automatic operations on them.

Oh – and choose your customers wisely.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• About The Intel Threading Tools, Our SIP Stack, and Me (0)
• SIP Multicore optimization – the aftershock (2)
• Human Vs Android (2)
• Integrity Porting (0)
• TODO or not TODO, That is the Question (0)

The What What What?

If you’re wondering what, it doesn’t really matter. You can read the Wikipedia page , but Dan only refers to a single element of the whole theory, and here’s the relevant Wikipedia quote:

When two systems are controlling the same variable with different goals, they are in conflict. When two opposing systems are locked into a static pattern, it is a source of psychological distress.

And also:

An internal conflict exists when a patient wants a perception to be in two incompatible states; the patient wants but doesn’t want a certain perception. For example, a person wants to eat in a healthy way but winds up eating too much or eats the wrong things.

Bear in mind that this theory relates to living organisms (animals, humans) but also to automatic systems. To sum up, we are talking about the case where someone, usually your customer, wants two different things to happen in the same time – he wants automation, reliability and simplicity, and at the same time, he wants control, versatility and transparency. Since your product can compromise these two ends, at best, the real problem is not in your product, but in how it is perceived by the customers. This perception is something you can control.

Take, for example, our BEEHD application.

SDK vs. Application

RADVISION’s Technology Business Unit (TBU), which I am part of, “manufactures” mostly Software Development Kits (SDKs), or “Protocol Stacks” as we fondly call them. These stacks translate the application’s “wishes” to the protocol level, meaning that if the application wants to send some indication, it calls the appropriate Stack API, and the stack builds and sends the appropriate message, notifies the application as to the response, etc.

However, applications written above the SDK tend to have “special needs”, for instance they want specific changes in the messages or proprietary messages. That is why our SDKs have a lot of hooks and callbacks, allowing application level control over even the most basic functions of the stack.

The BEEHD, for instance, is a rather closed application. Well, it’s almost closed – the APIs are the closest we could come to GUI buttons (while leaving the actual graphics to the customer). Some customers are ok with that, and are actually glad to leave concerns such as interoperability to us. Other customers are, well, used to working above SDKs, and their major complaint are “why can’t we change this?” or “why can’t we do things another way?”

There are a few possible answers:

1. Explain that this is an application, not a SDK, and it doesn’t work that way.

2. Change the application to allow the SDK-level access.

Both are pretty problematic: with option 1, you get frustrated customers; with option 2, you enter debugging hell when your application logic tries to cope with all the strange changes that the SDK level access imposes on it.

Higher Level Control Systems

As we learn from the PCT, “An internal conflict exists when a patient wants a perception to be in two incompatible states”. However, we also learn that “Higher level control systems may seek perceptions that don’t produce the conflict”, meaning that if our customers have a conflict resulting from conflicting needs, we but invoke higher level systems to resolve the conflicts – so we did.

What we did is sit down with the customer to talk, and reach answer no. 3:

3. Add the required (low-level) features as services controlled by (high-level) APIs.

Notice the difference between a feature, such as “add this field to that message”, and a service, such as “be compatible with this device” – services are our higher-level control systems. Simply put – we learn from our customers, and improve our product for the next customer. Think of us as car manufacturers adding a sports mode to accommodate the ’sporty’ drivers and not just the ‘calm’ ones. The car is a “closed application”, but instead of forcing hot rods to mess with the engine to squeeze out more performance, the car is made with a high-level control to accommodate them.

To prevent the distress from occurring in the first place, we could add to the product description something like “the BEEHD application supports several services and modes of operation to accommodate different environments and requirements. If you cannot find a suitable service in the current offering, please contact RADVISION’s customer support with the required services, and we will implement one according to you needs”.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• Lessons Learned From Rock Band (0)
• Integrity Porting (0)
• Visual Studio 2005 And Beyond (0)
• Software Is the New Hardware (2)
• Developing Products Around The One Question (0)

At the last Intel seminar I participated in, James Reinders, the Chief Software Evangelist & Director of Software Development Products at Intel, made a great comment when asked a question. “Intel has no opinion yet on that matter. I’ll give you my opinion, which usually becomes Intel’s”. I love this statement for it exemplifies our differences: I keep my opinions to myself, his become press releases.

As you might know, RADVISION participated in the Intel Developer Tools seminar, where they focused on the new Intel Parallel Suite tool that was just released. They asked me if I could speak at the event because of my success with the tool in its beta form, as well as the success I had with the post I later wrote about it (89 unique visitors. I’m getting pretty good at putting my hands on those unique IP addresses…J ). Before I was able to give them an answer, my boss answered for me, and without further discussion, I was off to the seminar.

Agenda

The seminar was all about multi core parallelism. An introduction was given by James Reinders regarding this new approach in programming, and about how Intel can help us developers achieve parallelism through the usage of their various tools. We had a 3 hour demonstration session on those tools, with live results on “before” and “after”. We also had some very… YAWN… interesting… z..zzz…zzzz… marketing presentations.

That said, a few lectures got my full attention, and I would like to elaborate.

The Academic Perspective

This lecture was given by Dr. Ami Marowka from Bar-Ilan University. The full name of the lecture was “Pitfalls and Issues of Multi-Core Programming: OpenMP vs TBB; The Academic Perspective“. First of all, he dramatically claimed, that parallel programming is very very hard (as if calling pthread_create() is that complicated. Right?). It is a revolutionary approach, very different from serial programming. As a professor, he claims that Israeli Universities do not teach this and if someone wants to learn, their only option is to be taught by an expert in the field, while on the job.

The second section of his lecture focused on what OpenMP and Intel’s TBB, can and cannot give us. As an example, he showed us a very simple code snip that can never be parallelized as-is by both approaches:

for (i =1; I < 10; i++)

a[i]= a[i-1] + 7;

As this is a case of data dependency, one cannot parallelize this code section because the result of one operation is dependent on the data calculated in a previous step.

He then showed some benchmark results of a comparison between OpenMP and TBB, suggesting that for most cases, TBB is better. This was interesting, as OpenMP defines compiler directives. If Intel implements OpenMP on their compilers, Why is that different from their TBB? I will get back to that later.

Anyway, I hope some students took good notes on his lecture, so I can copy them before the semester exams… Oh, wait; I’m no longer a student!

Parallelism Roadmap

The second interesting session was at the end of the day, again given by James Reinders, about the possible future parallel tools being developed by Intel. He spoke about vTune as the tool for the experts (planning to make it even more complicated), why they won’t integrate its technology into the parallel suite. “If I need to explain someone what ‘cache’ is, I don’t want him to use vTune. He probably needs to use the new suite” – his words. Good thing I know what it is. He explained a little bit about Ct which looks very promising, then switched to the chip domain, explaining a bit on Nehalem, Larrabee and Atom, and basically showed us Intel’s plan to rule the world.

The Main Event – My Lecture

This was a RADVISION presentation, and aside from Intel, we were the only other company speaking at this conference. Sagi Subocki, one of our product managers, was first to present an overview to our solution and then about our optimization experience. After that, he called me to the stage to give my lecture…

I don’t want to talk about it. I’m still recuperating. It was the scariest experience of my life: 200 people staring at me… I said I won’t talk about it. You can see it yourself:

They say I was OK. I don’t remember.

The Next Day

We made such a good impression, that the guys from Intel came to visit us in our office the next day. After the necessary introductions, I gave James Reinders the lecture I had the other day, only in English, and then shared some of my insights regarding the parallel suite, like what was missing, what can be improved, etc. He was kind enough to give us a glimpse at Intel’s software group roadmap for the next couple of years.

Getting back to the TBB/OpenMP comparison, he said that it is indeed very strange In his opinion, TBB should not be better than OpenMP, but rather just another approach to parallelism engineering. So this still remains a mystery that might forever plague us. He did indicate that there is a huge performance gap between the MS OpenMP implementation and the Intel one, in favor of the latter.

My Conclusions

• The obvious and more acute one: there are far too few females in the software engineering industry. Out of 200 participants in the seminar, I think only 10 of them were women. And it was kind of sad that there was not a single female lecturer.
• Parallelism is here and is not going anywhere. Even Atom will become multi-core eventually (“not promising anything”, cautions James). We will have to start thinking differently. Parallel optimization will be part of the regular software release cycle, just like the rest of the tools of our trade.
• The guys in Intel are doing a great job. I Never realized how big their software tools business is: IPP, TBB, vTune, MPI libraries, Ct, and much more.
• Evangelist? In the holy land??
• All in all, it was a very interesting experience. Can I go back to coding now? Please?

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• About The Intel Threading Tools, Our SIP Stack, and Me (0)
• Visual Studio 2005 And Beyond (0)
• TODO or not TODO, That is the Question (0)
• Lessons Learned From Rock Band (0)
• Interface Design & Perceptual Control Theory (0)

The first principle Dan mentions is “The One Question“.

Decisions, Decisions

Software development is a series of decisions. The Product Manager, customer and/or Project Manager (or equivalent) can provide requirements, statements of work, high-level design, even low-level design, but the person doing the actual coding is still left with many decisions:

• How to initialize?
• How to destruct?
• Which events should be synchronous?
• Use more or less parameters?
• What should be the exact call flow?
• What to do in an error case? Handle automatically or consult the user?

All these decisions could annoy your customer, but they could also make him love you forever. Do you know the feeling you get when something works just as you expect it to? It’s a Zen kind of feeling, of being one with the universe. You want that for your customer.

Dan Teasdale’s method for achieving this is called “The One Question”, meaning that instead of micro-managing every decision your team makes, you present them with a question that defines the essence of the product. Then each decision a developer makes is inspected in light of the One Question, as the result has to fit the question best.

The example Dan makes is related to the development of “Rock Band”:

“Is it an authentic band experience?”

• Big Rock Endings – yes
• Powerups – No
• Back from the Brink – yes
• Guitars on Fire – No
• Solo Bonuses – yes
• Minigames – Big No.

And Now for Development In General

Can one question, the “One Question”, really define something other than a game? Can it define an SDK – something that means different things for different developers?

The best way to test this is by trying to ask the One Question regarding our new and shiny BEEHD product:

Is this a high-end (video) phone experience?

I put ‘video’ in parenthesis because people may not have much experience with video phones, but we definitely know what to expect from our phones. And we know high-end experience from a low-end one. Different people may have different ideas as to how a “high-end video phone experience” should be, but this is true also for ideas of what a “rock band experience”.

Let’s try to make some decisions in view of the One Question we just asked:

• Simple, easy to understand state machine – Yes
• Low-level configuration – No
• Automatic error recovery – Yes
• Interactive operation – No
• Smooth video – Yes
• Delay – Big No

Surprisingly, this seems to work very well.

Now, what about SDKs? Let’s try to ask a question defining the essence of our Diameter stack:

Can it be used to build a robot army and take over the world?

Extreme question, I admit, but my first thought was of Star Wars, where Obi-Wan goes: “these are not the droids you are looking for”…

Pffft, Clones. This would not fly with my robot army. Every robot on the planet should be able to authenticate and authorize (or deny) and droid certificate. And they should do it quickly and reliably. So let’s make some example design decisions:

• Multiple levels of APIs – Yes
• Automatic error handling – No
• Network error resilience – Yes
• Static resource usage – No
• Expandable in every possible way – Yes
• Jedi Mind Trick prone – Big No.

It works well for SDKs too. This could potentially replace the classic product manager interface for answering every little design question. And it also relates well to Agile programming, if you’re into that. This would also be a good guideline for QA – test this like it’s going to go into a robot army, test that as if it’s a high-end communicator.

The One Question paints a big red target for where you want to go. Some developers may still miss the mark, but it will get everyone aiming for the same direction.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• Interface Design & Perceptual Control Theory (0)
• TODO or not TODO, That is the Question (0)
• Lessons Learned From Rock Band (0)
• Software Is the New Hardware (2)
• Web UI Protocols are Broken (0)

(not my band, but I like the drummer’s stage)

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• Interface Design & Perceptual Control Theory (0)
• Software Is the New Hardware (2)
• SIP Multicore optimization – the aftershock (2)
• Integrity Porting (0)
• Developing Products Around The One Question (0)

A Japanese experience

Why am I bringing Japan into this techie blog? Because of software porting. Porting software from one operating system to another is much like visiting Japan: everything seems familiar – same concepts, same services, same methodologies. But when you try to use them, you realize you’re not in Kansas anymore. Take Integrity, for example. We just finished porting our SIP stack to Integrity 5.0, and by “we” I mean Igor Novoseltsev, our resident expert. I sat with him to chat a bit about his experiences and lessons.

When I say, “porting the SIP stack”, I actually mean porting the Common Core, our OS abstraction layer. All of our products use the Common Core layer to access the network, use threads and locks, allocate memory, log, for standard data structures, etc. It saves a lot of time and effort, especially when porting. Once the common core is ported, there is only a minor effort to port any of the products that use it.

Integrity OS

Integrity is an operating system developed by Green Hills Software (GHS). It is a real-time operating system for embedded systems, designed with reliability and security in mind – this is achieved by using hardware memory protection to protect tasks from accidental errors or malicious tampering. It is proudly non-compatible with existing “80’s” operating systems (I think they’re dissing MS Windows), having been designed from the ground up. Luckily, that does not stand for “an unfamiliar set of APIs”, since Integrity supports the POSIX standards, common to many UNIX systems.

As our SIP stack contains an OS abstraction layer we call “common core”, and our common core already supports the POSIX APIs and was compatible with Integrity 4.0, we recently embarked on a mission to port it to Integrity 5.0, the latest release of the Integrity OS. Why? Because a customer asked for it, of course.

GHS provided us with the operating system files for the embedded system and their equivalent to the Microsoft’s Visual Studio IDE, Multi. Unfortunately for us, we usually use make files to compile our projects on non-windows systems, and we were reluctant to create and maintain a workspace for Integrity – having too many build systems isn’t a lot of fun.

Of course, the compiler and linker allow command-line activation, and although it was documented, there were some options and flags (used by Multi) which were undocumented. We asked for a little help from Green Hills representatives here in Israel, which were very responsive and provided us with sample make files, allowing us to compile our SIP stack and run it on the provided simulator.

Now all we needed was to try it out for real.

Going Embedded

The first rule of embedded operating systems is, and anyone who has worked on those will tell you that: it’s not over until it the board runs. Simulators have come a long way, but nothing can simulate the nooks and crannies of an embedded, real-time OS running on the actual hardware. However, it is also true that nothing is as frustrating and time consuming as trying to setup some new embedded system that just won’t do what you want.

The board we used was an Atmel ARM-based board (AT91SAM9263). We tried to bring it to life, only to discover, after a few frustrating days of work and with the help of the excellent Atmel support, that the Integrity version we had supports the AT91SAM9261, which, of course, is non-compatible with its -3 variant.

Again, GHS support came to our rescue and provided us with a compatible version, yet we discovered (in the documentation) that the only way to configure the board was with some device called a probe, or with a data-flash card. We had neither, nor the available time to order any (the customer was waiting), and so we decided to move from the Atmel board to a TI DaVinci board – we had a few of those due to the BEEHD project.

Unfortunately, things didn’t go smoothly there either. Again, documentation insisted that we have to use a probe to burn the kernel on to the board. And so GHS came through for us once more: they invited us to their offices, where they can burn the OS on to the board for us.

And so we drove over, with the board in hand, only to discover that the exact version we used was not supported. No surprises there, as we got it straight from the TI presses. (We and the TI homies are like this – you can’t see, but I’m making the thing with the fingers right now. See picture for details). But, as it is brand new, no support yet.

But while we were there, we saw another Atmel board lying around, and we were, like, “can you lend us a data-flash card?”, and they were all, like, “we don’t usually do that”. And so, to make a long story short, we drove back to our office with an Integritized data-flash card.

From there it was easy to bootstrap U-Boot to the card and setup a TFTP server that will get our binary application, copy it to the correct memory location (0×2000000) and run it. The wonderful assistance from the AT91 SAM Portal community (supported by Atmel) and the U-Boot project didn’t hurt as well. Another few days of work and we had it eating from our palm, that is, running SIP. Customer happy, sale done, money in bank, nice PR to show for it (a PR is the sales equivalent of a T-shirt, isn’t it?)

So, What Did We Learn From All Of This?

• Green Hills Software has a wonderful support team here in Israel. Thanks again, guys.
• Atmel has a great support team as well. With the amount of products they provide worldwide support for, it is nothing short of miraculous.
• Community sites are great for mental and actual support.
• Document everything as you go. The next programmer to try the same thing will run into the same problems, so why not save him some of the bother? Here’s what we now have on Integrity: Integrity for ARM Howto (566.96 KB)
• We now have a solution for Integrity “out of the box” for customers.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• Human Vs Android (2)
• Visual Studio 2005 And Beyond (0)
• Software Is the New Hardware (2)
• Interface Design & Perceptual Control Theory (0)
• Lessons Learned From Rock Band (0)

APIs used to be a matter of taste and design, pride and prestige; they were known to make or break an SDK. All this is about to change, as APIs are being standardized, and SDKs from different vendors will be interchangeable as your network card or USB mouse. Add to this the low cost of general-purpose processing units (GPPs) and you will understand why software is taking over traditional hardware roles (think about washing machines and cars).

Am I taking this too far? I may be late, as I said, but I’m afraid I’m dead on target.

Wikipedia Ride

First, a little disambiguation: web 2.0 has been with us for a while, with its service description language, remote procedure calls, Open APIs, you name it (and I’m not linking to the Wikipedia definition of these. If you don’t know any, just Google it up). I’m not talking about these. I’m not talking about network communications at all.

I’m talking about good old software libraries. I’m talking about a very specific form of Service-oriented architecture. I’m talking about Component-based software engineering and Modular programming, but not quite. I’m talking about a form of the old COM, KPart and Bonobo. I’m talking about, ladies and gents, what OKI, OpenInterface and many others are trying to do as I write these very lines: full encapsulation, reusability and interchangeability of any software component.

We’re still not there, of course, but it’s completely within reach. Look at how hardware is getting along just fine with the “plug-and-play” concept. I could go to any store, pick up any hardware, plug it into any computer, install a driver (which the OS does automatically for me in most cases), and in 99% of the time it will work like a charm. So why isn’t software like that, apart from (aforementioned) sporadic examples? It is all for the lack of one, agreed, open, standardized, application-programming interface.

We VoIP developers are used to having a standard under us, but will we adapt that easily to having a standard above us, in our connection to the application?

VoIP Industry Implications

Let’s pretend for a moment that we have such a standard. Answer these questions, please:

• Standardized or Proprietary?
• SIP or H.323?
• In-house or outsourced?
• Open Source or Commercial?

The answers are, by order: both, both, both and both.

Why would you settle for anything else? Especially if you can develop over the very same interface, first a proprietary proof of concept, then some basic SIP you whipped up, adding an open source H.323 when you branch out to the enterprise market, and replacing them all with a commercial implementation when your company grows. And when a new protocol arrives, you will just add that below your existing code.

A unified API may seem unreasonable when you consider that each service provider has its own set of requirements and limitations. I think that it is unreasonable, economically, to think that this can continue for long. Sure, there are advantages and specifics for each protocol type and implementation variant, but for mainstream make-a-call scenarios, a unified API is feasible. There will be some pushing and pulling between different power groups until the standardized API will be stable, and there will be some gaping holes allowing non-standard operation, but we’re used to that from the network protocols standards. Moreover, protocols learn from and imitate each other, so a novel functionality in one is likely to be mimicked in another. The developers of protocols will have to design protocol stacks that will be adaptive to many environments, perhaps specialized flavors of their toolkits to different environment.

It’s hard to guess the effect this will have on the industry. It will require more extensive testing, and some rethinking of the design, especially error handling. It will probably push the whole “strict protocols” thing straight out the widow. I expect script protocols to become big, since they solve many issues of implementation variants. I think system security will be better, but it would require more maturity on the part of users.

Eventually, I think every user (and his mother) will become a part-time system integrator, selecting between components on the fly. It will be like installing a mouse, keyboard or mp3-player*. If one SDK doesn’t work, the user will replace it with another that does. SDKs will eventually become a consumer product, part of the whole ecosystem of service mash-ups (and yes, I do believe service mash-ups won’t be just for know-it-all geeks very soon).

Whoever plays best with others will probably win.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• Integrity Porting (0)
• Why text-based protocols hurt your design (4)
• Naughty protocols, need spanking (0)
• Interface Design & Perceptual Control Theory (0)
• 5 “don’ts” when building a protocol stack (0)

Well, we’re back. We managed to fix what needed fixing.

As it was, people didn’t get the feed for a couple of months. Therefore, I’ll review what you missed.

TODO or not TODO, That is the Question

One of the customers went over our code, and found many TODOs in the code. That made me think: from the client’s side, isn’t checking for TODOs in our code a little bit counter-productive? The direct result would be that we will remove the comments from our code, and will be more likely to forget about them. When a programmer writes a TODO comment, it could mean one of several things, not all bad.

Commenting Can Be Bad For Your Soul

Following the post about the usage of TODO style comments, I asked the developers here at RADVISION to send me stories about inappropriate comments that they found in code. A wicked funny post, plus a guide for writing your own bad comments.

By the way, I also wanted to write an additional post about assertions, but Miško Hevery from Google’s Testing Blog beat me to it.

Why I Won’t Work For Joey DeVilla

Joey DeVilla writes about Captain Chesley “Sully” Sullenberger, and drives his point home with his recommended interview question: “What do you do in your spare time?” I don’t code, Joey, and I want my employees to have interesting hobbies.

“Hello, I’m a Slave” “And I’m a PC”

While your PC may be the grease lightning of computers, it usually can’t handle multiple, intensive memory, disk and network accesses. That’s where the Slave Computer, or SC, comes in, to aid the PC, the Primary Computer. This post covers some uses and utilities for a Slave Computer.

Five Bad Medicines for a Sick Code

I write about five signs that the developer in charge of the code could not figure out how to fix it. You still find a crutch here and a splint there added to keep the sick code “breathing”, like strange constants, data out of place, extensive error returning, code replication and code preservation.

About The Intel Threading Tools, Our SIP Stack, and Me

I asked Ofer Goren, a software engineer in the SIP Stack team, and one of those given the optimization task, to write a few words on multi-core optimization. Spoiler: they increased calls per second by 50% (!), to 94% core utilization.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• Visual Studio 2005 And Beyond (0)
• Software Is the New Hardware (2)
• SIP Multicore optimization – the aftershock (2)
• Code of Contact Movie Awards (2)
• About The Intel Threading Tools, Our SIP Stack, and Me (0)

“Hardware is cheap, programmers are expensive” says Jeff Atwood. So it’s better to spend your money on hardware, and not on optimizing your code. I wish we could say that to our customers and my boss, but he has this nagging habit of asking me to do things. Like, well, optimizing our code. More specifically optimizing it to this new multi-core technology. Hmpfff.

Therefore, over the past several months, multi-core optimization was my main focus. After identifying areas that can be optimized for scaling our SIP Stack performance to the level of CPU cores in use, we decided to put some effort into it. Hence the coming SIP Developer Suite version (5.5 GA2) will include code changes aimed to optimize multi-core performance in such environments.

I will describe in short what tools we used, why, and how they helped us with the task at hand.

What and Why

So the “what and why” questions were quite easy to answer. It was an obvious choice to look for some tool running on MS-Windows. After all, most of our development is done in a Windows environment before being ported to other operating systems, our IDEs and debugger run on Windows, and for me, at least, working with GUI is easier (sorry, but emacs is better than vi). We already had an installation of Intel Thread Profiler and Intel Thread Checker. In an incredible coincidence Intel approached us, suggesting we become part of the beta program for their next generation threading tools. Need I say more? I guess the choice was made.

How

So we installed the new tools, and started playing with them a little. After some fooling around, an eye-opening window appeared:

Wow. Out of 204 seconds of CPU run time, almost 60 seconds are spent on doing… nothing??? It just waits there? On a freaking Mutex?!  Heads will roll, I thought to myself. Let’s see who’s to blame:

Hmmm… we had several suspects, but it seemed that this “HandleIncomingRequestMsg” was just lying there, enjoying life, smoking (which is bad for you), while blocking everybody from doing their job…

I was interested to know if the legacy Thread Profiler tool agrees with those observations. The Profiler tool makes you work harder to get the same information, but I realized they share the same understanding: some cores are getting paid for no work at all! I knew we had to do something with this code.

To get a feeling of the extent of the issues at hand, Intel’s thread profiler can give an easy to read picture of CPU utilization by giving the concurrency level of the program running. The higher the right bars the better.

In the image above, you can see that most of the time, the test executed uses a single thread only, while the rest of the threads are idle. You can drill down from this view to your heart’s content and spend hours looking at your code.

And that’s how we identified potential areas that can be optimized, one at a time, focusing time on the largest bottleneck.

What I Learned

I was kinda clueless at the beginning of the process. I was told to optimize the code for multi-core CPUs. Well, great, how the heck should I do that? I just work here, remember?!  So the Intel Tools came to the rescue.. It told us everything we needed to know, in my all-time favorite GUI way, identified potential areas to work on, and gave us a methodical way to scale up and improve our code (Yeah, right. As if I wrote THAT code…). The work done improved performance on all architectures, not just Wintel. What can I say? They’ve got my vote.

My takeaways here are quite simple: when locking objects for a multi-core application that needs to scale:

• Make the locks you use as granular as possible (multi-level hashes, locks on objects and not on arrays, etc.). Bear in mind that while you do that, you increase memory usage and resources, so there’s a tradeoff here.
• Locks should be as short as possible. If you lock large pieces of code – you’re going to pay for it. with your time and with the cost of Intel’s tools

The Bottom Line

We started with 65% core utilization. After several months of work, we increased calls per second by 50% (!), to 94% core utilization. So if someone asks me, the Intel threading tools are the right thing for you. Smoking, in case you missed it, is not.

Download your free eBook guide on Video Conferencing, the Enterprise and You. Post from: Video over Enterprise

Related posts

• SIP Multicore optimization – the aftershock (2)
• Visual Studio 2005 And Beyond (0)
• Human Vs Android (2)
• Interface Design & Perceptual Control Theory (0)
• Web UI Protocols are Broken (0)