Who is it?

Wait! Skip a few years later, and this other plastic gadget-thing which dad bought showed us the number that was calling us. Nope, we don’t know this number.

Ring ring.

Sync

A few years later, a few years ago, I got a car-phone. It was a horrid thing, slow and stupid. In addition, it could not be synced with my mobile’s phone book. I had to “hack” it:  take the SIM out, put it in the mobile phone, copy all the numbers from the mobile to the SIM, stick it back into the car-phone, fix the butchered names (John Do~1, John Do~2, John Do~3), or at least the important ones, etc.

And if someone updated their number, god forbid, I had to update it manually on both phones. And it did not have text-to-speech, so I had to teach it how to pronounce the contact names if I wanted to use speech, eyes on the road and all that.

Still I got numbers I did not recognize, just like in the ‘before’ times. In that day and age, I expected more. I expected flying cars, but that aside, I expected the phone systems to provide me with a name, or the best approximation of a name (company, location) it can.

Workflow: How this SHOULD work

• Alice, upon buying her new phone, provides her name, the correct phonetic representation(s) of her name, selected web profiles, a flattering picture and a PIN number or some other password to grant permission to call her.
• Alice meets Bob, an old high school friend, and wants to keep in touch with him. She gives him her password.
• Bob looks up Alice, and provides the access password. His phone downloads her details from the network.
• Bob calls Alice, and Alice’s phone updates with his details.

It’s no rocket science, just applying the current social networking methodologies to the phone system. As for ‘private numbers’:

• Organizations must provide at least a company name and location.
• People who do not want to provide means for calling them back can provide limited information and no callback ability
• Those who want to remain anonymous can try to. Subscribers can decide if they want to allow anonymous calls, messages, etc.

Only one thing remains – backwards compatibility. Subscribers to POTS or older mobile phones can still have profiles and PIN numbers, even if they could not receive them. Until the subscribers create such profiles, the old caller id will still be supported. Maybe dad could get a new gadget, with an LCD screen showing the caller picture.

Is that gramps? This picture is from his army days. Just press ‘Ignore’.

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

Related posts

• Standardized Human Behaviour: Baby boom (1)
• Standardized Human Behaviour (2)
• Naughty protocols, need spanking (0)
• Interface Design & Perceptual Control Theory (0)
• Integrity Porting (1)

Let me explain: with most of the phones that you buy today, you are not limited to the OS supplied by the manufacturer and any updates released for it – courtesy of your friendly internet hacker. You can download tools to hack your device and flash any ROM on it – and it might even be legal. That is, if you’re ok with voiding your warranty.

Hacking? Who cares?!

A few days ago, a colleague asked me “what if the VC240 root password is leaked or hacked? Customers could install whatever they want on them!” Well, I said, first, we’re dealing with the enterprise market here, and they have a tendency to value warranty. Second, when we’ll really have to worry about that, we’ll know we’ve hit the big times.

Take my router, for example: Linksys WRT54G. Linksys was required to release the WRT54G’s firmware source code due to some legal hubbub. The result? A massive amount of third party firmware projects, which modify everything from capabilities to GUI – even converting the router to an access point or a repeater. This has lead to better product reviews and better sales. So much in fact, that when version 5 of the product turned out to have too little memory for the modifications, Linksys re-released version 4 under a new model name, so as to allow it to be hacked.

Of course, if your real business is selling (or licensing) the software for your hardware platform, like Apple’s doing with the iPhone or Microsoft with the Xbox, then hacking is a real problem. If you just sell the device, like Archos is doing with their Jukebox or Creative with the iRiver, why would you care what software it is running? The customer can replace the software with the Rock Box and it will only mean that you no longer have to service this device.

On the other hand, if you’re a software company, you’re in trouble: the sad truth is anyone can create software. I’m saying create and not write, since mashup services and ‘cooked’ ROMs are not exactly written.

Would you hack that?

Back to the VC240. We sell a nifty screen, with a heavy-duty camera, some really mean processing units, some badass codecs and a decent GUI.

Until VC240 fits into a blender, we can ponder about hacking.

Could someone hack that? Yes. By now you should know that anything can be hacked. Would he want to replace our software with his own? Seems to me that if someone wants a video conferencing unit, they could not create a better solution without a massive investment of time and effort, but maybe I’m wrong – open source groups have taken on major projects before and done extremely well.

On the other hand, if anyone would want to create a use for it that is NOT a video endpoint – a gesture activated screen, some kind of artistic video feedback, security, face recognizing workstation – it may actually make sense.

I have to admit I look forward to that.

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)
• Integrity Porting (1)
• If You Were A Fly On The Wall At These Great Companies (0)
• Writing code for human beings: IN, OUT and INOUT (0)
• Software Is the New Hardware (2)

While doing all of that, from time to time, we still need to address issues that we receive from our Customer Support department, cases which they cannot resolve without help from the R&D boys and girls. Surprisingly enough, one of those boys is I.

Last week Ran shared a case about TCP connection closing, and so I couldn’t do without sharing an interesting case of my own.

A bit of history

The case we have at hand is a simple case of type conversion. I’m assuming we all know what that is. We sometimes need to convert a 32-bit integer to 16 bits, or from unsigned long to a signed one, and while doing it, we need to be very careful. As the case of Ariane 5 shows, type conversion can sometimes blow up in your face.

The moral of the story is that if you’re going to use the same piece of software written for your old product (let’s say, the Ariane 4 missile) in your new product (Ariane 5, for instance) as well, you should take into consideration that the new product is most likely to be different.

In this case, the latter was much faster, so some velocity values that were never achieved on the previous version were reached on the new one, including a 32-bit integer value that was later converted to a 16-bit one. Of course, some part of the value was cut off by the conversion, leading to a crash – not a code crash, but of a missile crash. OUCH!

Bottom line: when stepping into that field, you aren’t alone. Giants walked there before you, and crashed.

A bit of SIP

SIP has a nagging habit of retransmissions. Instead of warning you that you’re dialing your mother, and by the end of it, you will surely feel guilty of something, it actually insists on fulfilling your wish. Therefore, it sends an INVITE message, and waits half a second for a reply. If none is received, it sends another one, but this time waits a whole second. Then 2, then 4, then it continues trying every 4 seconds, until 32 seconds have passed since the initial INVITE. During all that time it never stops to ask, “Are you sure you are calling your mother?”

Here’s the “official” documentation for it from RFC 3261, section13.3.1.4:

The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received.

The case in hand

So we got a call from someone in Customer Support. A customer complained that the last INVITE retransmission was sent after 487 milliseconds instead of 4 seconds. In fact, the last INVITE they experienced should have never been sent, as 32 seconds already passed from the first INVITE. Luckily for us, the customer also supplied a log file with the full details. All our toolkits can generate such logs, which helps us a lot during debugging. It lists API calls, message details and lots of other stuff. For each entry, there is also a timestamp, which is also a huge help.

Here’s the gestalt (edited for your reading pleasure):

Received INVITE
[...]
19:47:35.238112 Sent 200 OK
[...0.5s...]
19:47:35.740140 Sent 200 OK (retransmission)
[...1.0s...]
19:47:36.741197 Sent 200 OK (retransmission)
[...2.0s...]
19:47:38.742312 Sent 200 OK (retransmission)
[...4.0s...]
[...]
[...]
19:47:58.748456 Sent 200 OK (retransmission)
[...4.0s...]
19:48:02.749685 Sent 200 OK (retransmission)
[...4.0s...]
19:48:06.750914 Sent 200 OK (retransmission)
[...0.5s...]
19:48:07.239942 Sent 200 OK (retransmission that should not happen)

The Drill down

When a timer expires, our code reports it using a callback. The callback checks what time it is, what should happen next, and if needed sets up a new timer. We use 64-bit variables to measure time in nanoseconds. However, our timer APIs, use 32-bit variables (that represent milliseconds). This means that when the timer is triggered, we get its current value in milliseconds, and then convert it to nanoseconds.

So before setting a new timer, we take the value in nanoseconds, and divide them by a million to convert them to milliseconds. Therefore, our timer callback checks the time and calculates the interval for the next timer, if any. After all, if 31 seconds have passed since the first INVITE, there is no point in setting a 4 second timer. When a timer is set, it should also compensate for processing time and all kinds of other stuff being done between timer sets.

You might ask yourself what is the problem with converting 4 seconds, in their nanoseconds representation, to milliseconds. There is none. But what if, due to some compensation, we need to convert an ugly number such as 3,999,999,999 nanoseconds to milliseconds? We end up with 3,999 milliseconds, losing a lot of precision – almost a whole millisecond. Then, when the timer is expired and the callback is called, all the calculations are inaccurate.

This was indeed the case here. The code should have realized that 32 seconds have already passed since the first INVITE, but due to inaccurate calculations, it concluded that another retransmission should be sent. That, and all the compensations that we were doing, yielded the last unneeded message to be sent after 487 milliseconds.

The funny thing is (at least, for those who think those things are funny) that we had all the information we needed to avoid this in the first place. After all, we had the nanosecond values. We just used the wrong numbers in a wrong way – we used the converted milliseconds value instead.

Needless to say, the fix was a single change in a single line of code, using the right numbers in the right way.

Conclusion

I remember reading an excellent and recommended book from MS-press, “Writing Solid Code“. While not addressing this problem specifically, it does deal a lot with type conversions and the funny crashes you will experience if being light headed about it.

Lucky for us, we’re not building missiles… yet.

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

Related posts

• Software Is the New Hardware (2)
• Integrity Porting (1)
• Visual Studio 2005 And Beyond (0)
• Human Vs Android (2)
• About The Intel Threading Tools, Our SIP Stack, and Me (0)

It came from the beyond

Once upon a time, in a protocol stack far, far away, H.245 sockets were dying inexplicably. Packet captures on both sides saw the other side as closing the connection immediately after it was opened, causing the call to fail. It only happened during high load, and after further inquiry we discovered that it only happened when a socket was opened immediately after a socket with the same address was closed. Could it be that the socket was communicating with the dead?

Where do dead sockets go?

If they were good sockets, they go to socket heaven, also known as the TIME_WAIT state. In socket heaven, they wait until they are reborn. In Linux socket heaven, they wait 60 seconds. In Windows socket heaven, they wait 120 or 240 seconds, depending on the specific version. In socket terms, these times are an eternity, two eternities and four eternities accordingly. The socket’s address cannot be used in this time, but there is a shortcut: if the socket is set to reuse the address, it can be used again instantly.

Here’s the catch: if a packet somehow is delayed in the network, the new socket using the same addresses treats it as a packet meant for it. If the packet was meant to terminate the dead connection, for instance, if both sides terminated communications at the same time, the new socket will terminate. After close examination, we confirmed that this is what was happening in our case: both sides closed the H.245 connection at the same time, and then one of them reused the address and tried to reconnect, immediately receiving the connection close message left over from the previous connection and closing the connection and the call. We had to disable the ‘reuse address’ option, which forces the connection to wait, which in turn can cause the ports to run out under high load.

So what can be done to solve this issue?

1. Increase the size of heaven

Windows used a default port range of 1025 through 4999, which isn’t nearly enough. In Windows Vista and in Windows Server 2008, the new default start port is 49152, and the default end port is 65535 – which should last until the ports are available again in any reasonable traffic. On Linux it should be higher, but it depends on the exact kernel used. There is a nice guide here for increasing the port range on any system.

2. Limit the time in heaven

The fact is 60 seconds is a lot of time, not to mention 120 or 240 seconds. I recommend configuring Windows to a shorter delay (here), or tune up you Unix/Linux (here and here). In fact, let me Google that for you. I see no reason to use anything above 60 seconds, and even 30 seconds seem like eternity, in network terms, unless you expect to work in a high latency network, in which case, just take the highest latency expected and double it.

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

Related posts

• Determining a Timeout on That Network Event of Yours? Take Your Time (4)

Google offices, a few months ago

-       You see, the process is very streamlined.

-       Is it?

-       The user clicks ‘buzz’, gets a screen of privacy options, then a screen of his contacts to choose from.

-       You say?!

-       Ok, maybe it’s not that streamlined.

-       Is it.

-       I guess we could just start up with some defaults.

-       You say?

-       And pick all contacts as defaults, it will be ok for most people.

-       Is it…

Apple offices, a few months ago

-       You see, sir, we have great plans for the iPad. We’ll add multitasking, drag and drop, an SD slot, flash support, a camera – two, in fact, and we’ll write an open SDK for it!

-       No, no, no, no, double-no, and big no.

-       What? But the new UI, it’s almost ready, we have a new concept that will re-re-re-invent the whole market.

-       I. Want.

-       Yes?

-       An iPhone.

-       Right…

-       Only

-       Yes…?

-       Bigger.

-       Bigger, sir?

-       Bigger.

-       Not, say, better, with more features, re-re-re-revolutionizing-

-       You have an iPhone, right?

-       Of course, sir.

-       Don’t you think it’s great?

-       Why, yes, sir!

-       I want it to be like the iPhone… only bigger.

-       Right on it, sir.

Microsoft offices, a few months ago

-       We have this smart copy-paste feature.

-       Which part of KISS did you fail to understand?

-       No, it’s really cool. It has a history, adapts to the destination, synchronizes, offers suggestions-

-       SUGGESTIONS? SUGGESTIONS?! We don’t want another clippy the sodding office paper clip on our hands, that’s the last thing we need now!

-       But most testers said-

-       Let me see that! Ha! 20% said it was “confusing at start”, and 40% said they “could have done without it”. Forty percent!

-       But-but-

-       Look here – the Windows 7 Phone Series will have NO copy-paste! None! Code it out, NOW!

RADVISION offices, a few months ago

-       You see, the VC240 interface is much simpler than that of existing endpoints. We got great reviews on it.

-       Yes, I see. Just dial and send. All the options are tucked away in menus.

-       No interface like it. Great reviews.

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

Related posts

• VC240 – Is It Hack-Worthy? (0)
• Visual Studio 2005 And Beyond (0)
• Interface Design & Perceptual Control Theory (0)
• Integrity Porting (1)
• Human Vs Android (2)

We’ve just released a new version of the SIP Developer Suite. In the following post, I will try and describe the different steps required for such a miracle to happen. After you’ve finished reading, I hope you will have a better understanding of what we’re doing here, while waiting for our crops to grow in the farm.

Step One: Developing New Features

This is the obvious part. It starts with our Product Manager randomly selecting some features, out of those RFCs or drafts for RFCs on the IETF site. Then he tells us something like “after carefully reviewing the market, and while visiting every single customer we have, I’ve decided that our SIP suite must support…” these features. “Make it so, Number one!”

In this version, for example, we added support for RFC 4662. It is a very important addition, that deals with processing of… um… some sort of… and also with… and that too. Another thing we added is support for Android OS, as I told you before. And some new headers that were added as part of the 3GPP initiative.

Once that phase was finished, the real complex fun started.

Step Two: Compiling on all Supported Operating Systems and Testing

I mentioned several times the fact that the SIP suite supports many OS – from Microsoft Windows with its different flavors to embedded OS, such as VxWorks, PSOS, Nucleus and a lot of others, and even some real strange ones, like the Mac OS.

Once we finish developing, it is time to check our code and verify that everything is compile-able at least. The fact that we have an OS-agnostic layer helps, but there are still differences that should be taken care of. OpenSSL, for example, has different const-qualifiers in some functions for VxWorks comparing to Solaris due to different versions installed with each. Tcl/Tk has similar issues.

Testing is a very important thing to do. Or so they say. I’m still waiting for a proof. However, till then, we’re testing. And that means running every single sample application we have on various OS. Then, we run our internal multi-thread tester to check for appropriate multi-thread behavior. While doing that, we use our test application to test new features as well as regression testing.

Of course, our QA team is also in the loop, sticking their fingers inside our precious code, finding all those things we deliberately put in there to see if they find them.

Step Three: Compilation Flags – fun fun fun

Reading through our readme files, one can see that the SIP suite has a nice list of compilation flags to suit various needs and features. IMS, SIMPLE and SRV are only some examples. Compiling with all the combinations available can be quite amusing. On a slow PC, it can even be a good excuse for a day off. If you want to cause one of us developers to develop an acute case of heart disease with high blood pressure, ask him to compile with NO_TRHEADS and NO_LOGS. Then, ask him to fix all the resulted warnings. Its kinda funny to see someone with steam coming out of his ears.

Step Four: Documentation

When talking about “documentation”, I do not mean inline documentation. Like every other good programmer, we are documenting as we write our code… ahmm, right. But then, we need to put them on the .chm files, .pdf files, release notes and readme files, and send them for review to our technical writer, and then fix everything after she finds out that English is the only language we are NOT using. At least, not the one spoken in the civilized world. Then, we put those fixes in the inline documentation again, re-compile everything just to verify we didn’t accidently comment-out main(), see something you forgot to pass on, send it back to the tech-writer, and so forth. At that point – usually three days before the release – you might see our tech-writer lurking the corridors holding a knife, hunting the last person who sent her those last minute additions.

Step Five: Packaging

Linux code is tar-ed and gzip-ed, with the source code CR’d. Windows code is zipped, with the source code CRLF’d. Common-Core is a separate package. SigComp as well. As is IMS, SIMPLE, etc. You get the idea. Everything should be packaged according to its designated OS, with only the relevant files (no point in packaging an MSDev vcproj files for Linux compilation, right?), and with the appropriate compression tool. We have a script for that, but this script should be updated every time a new module is added, whenever a new OS is supported, and whenever we feel bored and want to play with it a little.

So we package, and then un-package and test the results to see that everything is compiling and running. Of course, it fails dramatically, and we need to debug the script to see where we messed up, re-package, and again. And again. And again.

Once all is working, always on the last minute of the last day of the promised Q, we ship it.

Step Six: Vacation

Yeah, right!

Conclusion

There is no moral in this story. Just a description of what I was doing since my last post here. Like always, it was a stressful month. Now that I got Tsahi off my back, I’m off to the beach.

And when I’m back, I am sure we will organize things here a bit better for the next time. I will mention that in the kick-off meeting…

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

Related posts

• Human Vs Android (2)
• Software Is the New Hardware (2)
• Integrity Porting (1)
• Why is VoIP so hard on firewalls and NATs? (1)
• Visual Studio 2005 And Beyond (0)

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 (1)
• A New GA is Born (0)
• About The Intel Threading Tools, Our SIP Stack, and Me (0)
• Software Is the New Hardware (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 (1)
• 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 (1)
• 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)