Pardon me—whose unwanted baggage am I tripping over?

The storm had cleared and with it took much of the humidity. The temperature was still warm, but manageable. Best of all a gentle breeze was blowing down off the mountains.

I went walking around Temple Square, drifting in and around wedding parties, tourists, and Mormon Sisters who were helping folks. I walked by one Sister and she gives me a big smile, asking how I was doing and if I needed help. I realized I was next to the Tabernacle and had hoped to hear the Choir sing. When I asked the young lady about choir performances, she not only gave me times when they were playing but enlisted the help of another sister to work out a strategy for me so that I could get excellent seating. They worked with the precision of enlisted soldiers determined that I, visiting from San Francisco, had a chance to hear the choir at its best (tomorrow morning, be there early, sit in this location – got it, Sergeant).

I also splurged on a horse-drawn carriage ride throughout the city – I am a sucker for horse-drawn carriages. My driver, Emily, obviously loved the city, and the horse, Cleo, was young and very spirited. I had a wonderful trip, not only seeing what really is a beautiful city – a unique city – but also talking with Emily and enjoying the antics of Cleo (who does NOT like loud rock and roll by the way).

After the ride, I asked someone on the street for directions and she not only pointed me out where I needed to go, but also took me by the arm, walked me to the end of the street and literally pointed out the building I was looking for, chatting with me the whole time about making sure I see the Beehive house and the Joseph Smith Museum and…and…

Sometimes we can view things, people, and places through glasses shaded by past trauma and sadness. Rather than rose-colored glasses, these are smoky at best, fogging our vision and impacting on our interpretation of what we see. When I walked out this morning, comparing the City of Salt with young memories, all I could see was Ozzie and Harriet on one side of the street, Undergrounders on the other. This afternoon, I took the glasses off and I saw a city made up of Undergrounders and Ozzie and Harriet, true; but I also saw people like me, like you.

I walked around downtown enjoying the beauty when I noticed a crowd gathered around a group of young women with harps. These were students and friends of Elizabeth Smart the young girl kidnapped from her home June 5th. They were performing at a concert to raise awareness of Elizabeth’s kidnapping and to provide support for Elizabeth’s parents.

Elizabeth’s parents spoke first, not 15 feet in front of me, mother stoic, father breaking down in tears. In another place, in another time, they would be Ozzie and Harriet. Today, they were the grief-stricken, terrified parents of a little girl who was stolen from everything she knew, a family of love and taken for what reason we may never know.

And then the harp players, ages 4 and up, started playing:

Bah, Bah, Black Sheep have you any wool?

Yes, marry have I,

Three bags full.

A day in the life of a technical architect

Client: When can you tell me what you think of the software?

Me: When do you need the evaluation?

Client: Tomorrow.

Me: Tomorrow?

Client: Yes, we’re meeting with our clients tomorrow.

-sigh-

Me: Well, what’s the potential user load for the software

Client: Half a million customers

-pause-

Me: At once?

Client: Yes. What do you think it will take?

Me: A miracle

P2P Discovery

What kind of core do Kazaa and its supernodes have? Is it iron? Gold? Or is it more of an aluminum core because the cloud that supports the Kazaa P2P network is still malleable — the Supernodes that provide the cloud services are fluid and can change as well as go offline with little or no impact to the system.

I imagine, without going into the architecture of the system, that more than one Supernode is assigned to any particular subnet, others to act as backups, most likely pinging the primary Supernode to see if it’s still in operation. Out of operation, the backup Supernode(s) takes over and a signal is sent to the P2P nodes to get services from this IP address rather than that one. The original Supernode machine may even detect a shutdown and send a signal to the secondaries to take over.

Or perhaps the Supernode IPs are chained and the software on each P2P node checks at this IP first and if no response occurs, automatically goes to the second within the Supernode list and continues on until an active Supernode is found. This would take very little time, and would, for the most part, be transparent to the users.

Again without access to any of the code, and even any architecture documentation (which means there’s some guesswork here) the algorithm behind the Supernode selection list looks for nodes that have the bandwidth, persistent connectivity, and CPU to act as Supernodes with little impact to the computer’s original use. The member nodes of each KaZaA sub-net — call it a circle — would perform searches against the circle’s Supernode, which is, in turn, connected to a group of Supernodes from other circles so that if the information sought in the first circle can’t be found, it will most likely be found in the next Supernode and so on. This is highly scalable.

So far so good — little or no iron in the core, because no one entity, including KaZaA or the owner’s behind KaZaA, can control the existence and termination of the Supernodes. Even though KaZaA is yet another file sharing service rather than a services brokering system, the mechanics would seem to meet our definition of a P2P network. Right?

Wrong.

What happens when a new node wants to enter the KaZaA network? What happens if KaZaA — the corporate body — is forced offline, as it was January 31st because of legal issues? How long will the KaZaA P2P network survive?

In my estimation, a P2P network with no entry point will cease to be a viable entity within 1-2 weeks unless the P2P node owners make a determined effort to keep the network running by designating something to be an entry point. Something with a known IP address. Connectivity to the P2P circle is the primary responsibility of a P2P cloud. KaZaA’s connectivity is based on a hard-coded IP. However, small it is, this is still a kernel of iron.

We need a way for our machines to find not just one but many P2P circles of interest using approaches that have worked effectively for other software services in the past:

We need a way to have these P2P circles learn about each other whenever they accidentally bump up against each other — just as webloggers find each other when their weblogging circles bump up against each other because a member of two circles points out a weblog of interest from one circle to the other.

We need these circle to perform an indelible handshake and exchange of signatures that become part of the makeup of each circle touched so that one entire P2P circle can disappear, but still be recreated because it’s “genetic” makeup is stored in one, two, many other circles. All it would take to restart the original circle is two nodes expressing an interest.

We need a way to propagate the participation information or software or both to support the circles that can persist regardless of whether the original source of said software or information is still operating, just as software viruses have been propagated for years. Ask yourselves this — has the fact that the originator of a virus gone offline impacted on the spread of the said virus? We’ve been harmed by the technology for years, time to use the concepts for good.

We need a way to discover new services using intelligent searches that are communicated to our applications using a standard syntax and meta-language, through the means of a standard communication protocol, collected with intelligent agents, as Google and other search engines have been using for years. What needs to change is to have the agents find the first participating circle on the internet and ask for directions to points of interest from there.

A standard communication protocol, meta-language, syntax. Viral methods of software and information propagation. Circles of interest with their own DNA that can be communicated with other circles when they bump in the night, so to speak. Internet traversing agents that only have to be made slightly smarter — given the ability to ask for directions.

Web of discovery. Doesn’t the thought of all this excite you?

Iron Clouds

A true P2P cloud does not have a core of iron. By this I mean that there can be no static IP or server providing the gateway or facilitating the communication between nodes within a distributed application.

You can argue this one with me for years and you won’t convince me otherwise. I know that Groove has an iron core cloud. I know that Userland is thinking of an iron core cloud that can move about the nodes. UDDI is based on the premise of a centralized source of information about services that just happens to get striped and mirrorer. Striped — chunked off. Mirrored — distributed to different servers. And don’t focus on the the distributed in the latter, keep your eye on the server.

Server == iron

iron == control

Freenet comes closest to being the truest form of a cloud but there is an assumption that the gateway to the cloud must be known in some way, a pre-known entrance. According to the Ian Clarke’s Freenet: A Distributed Anonymous Information Storage and Retrieval System, “A new node can join the network by discovering the address of one or more existing nodes through out-of-band means, then starting to send messages”.

Can we have P2P clouds without some touch of iron? Can we have transient gateways into P2P networks without relying on some form of pre-knowledge, such as a static IP?

Ask yourselves this — I’m looking for information about C#, specifically about the CLR (Common Language Runtime) and the Common Language Interface (CLI).

Keys are: C# CLR CLI

Go to Google, enter the words, click on I’m Feeling Lucky — and say hi to me in passing.

We don’t need P2P clouds with cores of iron; what we need is new ways of looking at existing technologies.

P2P Services

The Don Box discussion about HTTP was a good read with valid points.

From a P2P, not a web services perspective, we need to guarantee certain capabilities in P2P services that we take for granted in more traditional client/server environments. This includes the following:

 

  • Transaction reliability — the old two-phase commit of database technology appears again, but this time in a more challenging guise.
  • Transaction auditing — a variation of the two-phase commit, except that auditing is, in some ways, more fo the business aspect of the technology.
  • Transaction security — we need to ensure that no one can snoop at the transaction contents, or otherwise violate the transaction playing field.
  • Transaction trust — not the same thing as security. Transaction trust means that we have to ensure that the P2P service we’re accessing is the correct one, the valid one, and that the service met some business trust criteria (outside of the technology realm with the latter).
  • Service or Peer discovery — still probably one of the more complicated issues about P2P. How do we find services? How do we find P2P circles? How do market our services?
  • Peer rediscovery — this is where the iron hits the cloud in all P2P applications I know of. You start a communication with another peer, but that peer goes offline. How do you take up the conversation again without the use of some centralized resource? Same could also be applied to services.
  • Bi-directional communication — This is Don’s reference to HTTP’s asymmetric nature. Peers share communication; otherwise you’re only talking about the traditional web services model.

The file transfer nature of Napster or Freenet, and the IM nature of Jabber don’t necessarily consume all of these aspects of P2P applications, so haven’t necessarily pushed the P2P bubble to the max. However, when we start talking about P2P services — a variation of web services one could say — then we know we’re going to be stretching both our technology capabilities, and our trust of the same.

Fun!