February 2008 Archives

Managing Update Notifications

| 2 Comments
| | | |

Ok, so you enjoy knowing when a zoomshare friend updates their site via Message Notifications, but, well let's be honest, you have a lot of friends and if you spend one more day clearing out yet one more inbox your going to scream!

If only there was a way to switch off the default setting and select which friends you wish to receive update notifications from ...

Well now you can! Zoomshare users can now control which friends they receive update notifications from within their Friend List. For each friend a new option titled 'Edit Preferences' has been added to the right-hand side of the friend's screename. To toggle the setting off or on simple click on the 'Edit Preferences' to reveal the 'Receive Update Notifications' checkbox.

Zoomshare Edit Friend Update Notification Preferences
Editing Update Notification Preferences

By default this setting is 'on' so the checkbox will be 'checked'. To toggle the setting 'off' click on the checkbox to uncheck it, then click on 'Save Preference'.

Experienced zoomshare users may notice that the 'Edit Preferences' feature expands the previous 'Add Description' feature in which a user could leave a personal description or note to themselves about each friend. This option still exists under the 'Edit Preferences' feature and behaves in a similar manner as the 'Add Description' feature.

To add a personal note or description about a friend, simply replace the "Add Description" text with one's personal comment and select 'Save Preferences' after first clicking on 'Edit Preferences.

Enjoy!

Part II: On Two Hours Sleep

| 0 Comments
| | | |

This is the continuation of a story begun in "The Move" in which our heroes battle nefarious network gremlins in order to save zoomshare from imploding under its own weight.

By 7am, when everyone else was waking, I was getting into bed. Other than a need for a good long nap, all seemed well. The move from colocation to colocation took a little longer than planned, but judging by the performance we saw before leaving the building zoomshare was running better than ever.

As I closed in on being awake for 24 hours I knew I didn't have a taxing day ahead of me, I had planned my schedule accordingly at least. However, I still had some work to do and tops on that list was a check-in with zoomshare in a few hours, so I set my alarm for 9 am and closed my eyes.

I don't remember the alarm going off.

10 am. I could have used some more sleep, but that could wait just a few minutes. A quick check-in on how zoomshare was handling the morning traffic and then a few more hours of shuteye.

I don't think I even got in my chair, let alone logged into my computer.

I had voicemail. In fact I had a voicemail from kree10 that was just a few minutes old.

Not good news.

Not good news at all, in fact. He was on his way back to the colocation facility. No one from the office was able to connect to any zoomshare site, verifying in turn that everything was in working order. Moreover, it was looking like a good percentage of our users were having issues as well, which meant it wasn't localized to just one network connection or path.

I gave kree10 a call, He asked me to meet him and to bring any spare any network switches I might have with me. He was bring one as well, just I case. So much for getting more shuteye.

I dressed, I disassembled part of my home network, unplugged my network switch, picked up my laptop and headed out the door.

The Odd Couple
Why bring along a network switch? I believe by the time I was on the road back from which I had come peenworm had determined that about 60% of the network packets from our office were being dropped on their way to the zoomshare servers in their new home. Most of the equipment was the same equipment that had been humming along at the old location just a day before. Most, but not all.

Some of the new equipment already in place before the move included a new network switch for managing network traffic between the various servers. When all is working correctly network switches properly inspect network data packets as they are received, determine their source and destination and forward the traffic appropriately. When things go wrong, well...things sure didn't seem to be going right.

The funny thing was peenworm had seen something like this within the past few months at the old facility as well. It wasn't caused by new equipment so much as by an uptake in network traffic. It was a network communication issue, a duplex mismatch to be exact.

Ok, see a network connection can be unidirectional or bidirectional. In either case this is known as duplexing. Our networking equipment, our switch helps determine if there is either a bidirectional "two-way path" between the two connected parties or a unidirectional "reverse path". Just as it manages the who, what and where of the network traffic the switch helps manage the how. But if any of the equipment on the network is misconfigured, then boom, a network collision and network data disappears, literately into the ether.

In any case the quickest way to straighten out the issue was going to be swapping out the new network switch with another model. Traffic on the network would right itself, packets would stop getting lost and after a little rest we could property reconfigured the newer network switch and place it back online when ready.

If only.

After meeting up with kree10 we tried our switches. One network switch replacement later and no improvement. Two networks switches later and still, no improvement. Something else was causing the network loss. But what?

I Dare Say Mr. Holmes
In "The Move" I mentioned feeling out of place as a software engineer in a network engineer's world. In the world of computing there are hardware and software "layers" that allow engineers to develop ever more powerful tools. Each "layer of abstraction" removes a level of complexity out of one's hands such that other problems can be tackled. As a web developer, for example, on any given day I don't have to worry about programming networking protocols to mange duplexing issues, as that's all been taking care for me by someone else.

A third wheel I said I felt like, sort of like Dr. Watson tagging along as Sherlock Holmes probes his client's inner thoughts in search for clues ... and an answer.

And yet in Arthur Conan Doyle's tales Dr. Watson was a medical man, a practitioner of science. He too could put his analytical problem solving skills to the test, even in unfamiliar waters. After all Holmes' axiom rings true in just about any logical situation, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth."

If its not the network switch it must be some other piece of equipment. Alas, logic has a way of escaping one's sense after 36 hours and just a few hours of sleep. Frustration starts to set in, and that sure was the case for all three of us after a few more hours of troubleshooting. The office was having issues connecting, but at the facility where we plugged into the net everything worked better than fine.

We had tried everything we could. It sure seemed like it wasn't a problem with any of our equipment. Therefore, as Mr. Holmes would correctly point out, it must be a problem elsewhere. When the floodgates were opened and all of the traffic trying to get to zoomshare came rushing in, something starting acting up.

But we couldn't think straight; perhaps our logic was escaping us. We must have missed something. It couldn't be a problem with the colocation facility could it? We didn't see any network issues.

Could it be with our new Internet service provider? The tech we talked to sure didn't see any issues from his workstation.

Any yet ... To be continued in "The Analogy"

Brand New Apple //c

| 0 Comments
| | | |

Dan Budiac recently won an eBay auction for an unopened Apple //c and, yeap, he opened it. Since I work with one every day, you would think I'd be unimpressed. Well, I am impressed. I mean looking at the photos from the unboxing, the unaged snow white design just pops right out at you. Simply Amazing.

 

Part I: The Move

| 0 Comments
| | | |

Recently we moved zoomshare into a new home. Alas, the move didn't go quite as planned. What follows is an "insider's" story of the move, what went wrong and how, ultimately, zoomshare came back to life.

On any given day the traffic zoomshare generates is significantly less during the early morning hours compared to peak hours during the afternoon in the United States. Early morning zoomshare's over 750,000 sites receive approximately 125,000 visits in total between Midnight and 5am Central Time. Peak hours, between Noon and 5pm, zoomshare sees about 4 to 5 times as many visitors, some 550,000.

Obviously, we scheduled an overnight maintenance window to move the necessary zoomshare equipment. Given that, I left the office early Tuesday to rest up. My plan was to skip dinner, roll into bed and get a quick nap in before meeting up with kree10 and peenworm.

It Begins
As time marched toward Midnight with nary a sheep in sight to count, I rolled out of bed and started to get dressed. I should have known then something was up. After watching semis whoosh by at a highway oasis while eating a burger, soda and America's favorite french fries I meet up with kree10 and peenworm to start.

What exactly is involved in moving servers from one colocation facility to another? Well since a computer, server or otherwise, requires a connection to the Internet, the first step before moving is to setup service at the new location. In the case of servers this also means getting and assigned new static IP Address so the computers making up the system can be found. More importantly, the new IP Addresses need to be associated with the existing domain name, zoomshare.com. Therefore, from a technical point of view this means configuring servers to route traffic on their new home network by assigned them their new IP Addresses as well as configuring DNS to associate the new addresses with the existing zoomshare domain(s).

In the physical world, this means mounting and unmounting computers and network equipment in a server cabinet, running network and power cables and of course lifting and shuttling equipment between locations.

It sounds simple, but one has to realize that the "application" that is zoomshare is a complex system of hardware and software. In hardware zoomshare currently accounts of at least half a dozen pieces of equipment; servers, switches, routers and firewall, on two different networks, one public and one private. In software, the zoomshare application code is dependent on several instances of web server software, a database engine, email transfer agent, operating system and a heck of a lot of custom code that's distributed between the various servers and of course must be able to communicate between each other at different network layers.

Minor Troubles and Tribulations
Alas, colocation facilities tend to be very utilitarian since the business model for providers of these facilities is to maximize space, power and bandwidth for housing computers. This means they tend to be cold, noisy and cramped. Moreover since my main job on zoomshare is as a software engineer and not as a system administrator, it didn't take long after meeting up with kree10 and peenworm to feel like the proverbial third wheel, not much to do and nowhere to be but in the way. Soon however peenworm had the servers we needed to take with us offline and with kree10's van loaded up we moved on up and started reconfiguring servers for their new home.

Each new home has its own little quirks and idiosyncrasies to them. The same goes with colocation facilities. Each facility has its own take on how things should work and run, procedures and rules to follow and work by. For example, the new home of zoomshare has a loading dock that can be used to deliver equipment, be it delivered by hand or freight.

As time goes by one learns how to navigate the little quirks in a new home. They can become reassuring where originally they were unsettling. For a colocation facility, this might mean the different between how a procedure is written and how it is actually followed. Alas, it doesn't help, it's not reassuring, when you are just beginning to learn how to navigate the facility's procedures and something goes amiss. In the case of the loading dock, it was a new security guard on staff that threw me off as I tried to get access to the loading dock from the inside while kree10, van and equipment waited in the freezing subzero cold outside.

After a bit of wangling for access to the dock and a handcart to load the equipment on kree10 and I met up with peenworm who had already started preparing the new server cabinet for zoomshare.

The End?
To me it seemed down hill from here on out. Sure, nothing as complex as this goes quite as planned, but we seemed to have been able to navigate the bumps in the road without going bust. Moreover, most of the physical work and for the most part my helpfulness started to come to an end as each server was added to the cabinet, secured as much as possible, wired and powered up.

We had already prepared the new facility a week before hand as much as possible and now that we had the remaining servers mounted and wired all that was left was for peenworm to reconfiguring and verify everything was online. With that zoomshare would be back to life.

In all it took us a bit longer than planned to get all the equipment up and running. All should have been running by 5am, just as traffic to zoomshare for the day would start to increase. We had figured it would take us until 3 for the actual move, 5 in case anything went amiss. By 6 we had everything wrapped up and the "little problems" solved. Judging by the wireless network public network access to zoomshare was snappy and running faster then ever. All was done with only a handful of issues too minor to mention. What's a little misunderstanding about a handcart between friends? After all, all's well that ends well.

Or was it? Find out in "On Two Hours Sleep"

About the Author

Paul is a technologist and all around nice guy for technology oriented organizations and parties. Besides maintaining this blog and website you can follow Paul's particular pontifications on the Life Universe and Everything on Twitter.

   
   


Subscribe:
Add to Google Reader or Homepage
Add to My AOL

Add to netvibes
Subscribe in Bloglines
Add to Technorati Favorites

Powered
CentOS
Apache
MySQL
Perl
Movable Type Pro