The Social Media Club is netcasting Friday, August 31 at 10am pst on BlogTalkRadio. Chris Heuer, Robert Scoble any myself will be talking about a topic that vexes even the best bloggers… how to balance authenticity, credibility, and authority in the blogosphere. It’s a call-in show, so dial 1 646 716 9346 and join the conversation.
The backstory
The topic was prompted by a recent bit of hair ruffling between bloggers. I don’t want to recap the posts and comments. You can find the post that kicked things off here. After being taken to task for “heavy breathing” about companies and products (among other things) Robert’s reflective response raises the conversation above the noise and suggests ways to avoid flaps like this in the future.
The Show
This is the first in a regular series of Social Media Club talk shows. We want you to call in, so join us on Friday, August 31 at 10am pst. Dial 1 646 716 9346 and join the conversation.
The Silicon Valley chapter of the Social Media Club met at Yahoo last night. The topic was Social News Smarts, Community and User Expectations on Social News Sites. I had the pleasure of introducing Stacy Bond of Audioluxe. She moderated a panel that included:
I would have paid more attention to the panel, but I was assisting Steve Sargeant of Effible Communications set up the audio system shown below. It was designed to bring remote callers into the event via Skype. It sorta, kinda worked.
The system worked as long as the person on the mixing board had fast enough fingers to mute the microphones while the remote callers were speaking. Without muting the mics, the reverb and other audio artifacts were unavoidable. The delays introduced by Skype are not so much about Internet traffic loads as they are about several cycles of audio compression as the cell phones and Skype do it their way.
I don’t like setting up systems before testing them. We were skating on thin ice in that regard last night. Thanks to Steve, we got much of it right.
Next month we’ll be using Ustream and BlogTalkRadio to cover the meeting. Our topic will be the changing face of corporate video. Even if you can’t join us at PodTech on September 12, I hope you’ll be able to catch our stream or archive files.
Although all the blame cannot be laid at Microsoft’s feet, I now recall a persistent dialog box that urged me to reboot after a system update on the day Skype went down. I thought the reboot dialog might be a virus that wanted to take over my computer, but it was only dear, sweet Microsoft. By forcing a system update on millions of computers as once, they created the perfect storm. Julian’s hypothesis (see my previous post) sounded good, but it wasn’t the culprit. It was millions upon millions of log in requests that did the system in.
So what are the lessons?
First, make no assumptions about the problem unless you know the whole system. The definition of whole system now includes your application and everything else your users are plugged into. That’s an infinitely complex hairball.
Second, companies have a responsibility to keep their customers informed. Skype gets a C+ in this department given the lags in their explanations.
Third, everyone as a right to complain about anything. I don’t care if you paid for it, got it for free, or stole it. If it doesn’t do what it was designed to do you can bitch about it. Hell, as far as I’m concerned you can bitch about a clear blue sky. I may not agree, but I’ll stand by your right to say something.
And yes, I’m still using Skype!
But unlike the Godfather of Soul, James Brown, I can’t “get up offa that thing and dance ’til you feel better.” Not after 48 Skypeless hours. I still want an explanation of what happened. Skype says they won’t have a straight story until Monday.
In the meantime, among all of the pissing and moaning, one comment by Julian Cain of Pando provides more insight than any of Skype’s attempts to tell users what’s going on. Julian’s comment on GigaOM nails the problem with Skype’s data hash tables (DHT):
Skype introduced a flaw into the network that dealt with “routing” and “fucked” the “decentralized data store aka DHT” this in turn ran clients on a RANDOM search of Supernodes which at this point were well booted off of the network.
It is a huge cycle, no matter how many bugs they “fix” in the “central servers” it will take many days for N nodes to become Supernodes so they can route X data from peer A to peer B. This is NOT minor, a fix to the centralized server code base to relay data to N Supernodes there is lack there of, resulting of a very segregate network. Right now there are approximatly 10,000 sub Skype networks instead of 1 Single “in sync” network. When this “data store(see DHT) is in sync globally then the Skype network will be again STABLE.
I know this is very broad but, unless magically all of said nodes can recreate the “single overlay (DHT)” then nothing will be in sync. You will see delayed messaged, delayed or incorrect profiles and presence.
My take, in the end is give it 48 more hours and it may be semi-stable, but hey this is what you get with using end users as your own redundancy…
The fallout from Skype’s outage episode is likely bring closer scrutiny to many peer to peer architectures that we’ve grown to enjoy. In that sense I owe an apology to Skype for my earlier post about rolling back servers to a previous build. True peer to peer does not have servers in the client-server sense of the word.
Does Skype’s outage call P2P architectures into question? If you need the security of redundancy and failover, P2P is not your best bet. My argument is that if VOIP phone service is going to be competitive, they must address the issue of rapid failure recovery. I just don’t think that’s possible in the P2P world, is it?
