Categories
Web

Browser breakage

NJ Meryl has been having some interesting challenges accessing a specific web site so she tried accessing it using an older browser – Netscape 3.x to be exact. Well, as she found out, Burningbird breaks with Netscape 3.x.

My reaction? No offense to the world, but I could give a flying squirrel (this is a polite euphemism you understand) if a 3.x browser can’t access this site. And the person trying to access the site with Lynx might as well give up now, too.

I’ve been working the cross-browser and cross-version issue since the first release of IE in the 1995/1996 time period (can’t even remember specific date any more), as shown in this old article at Javacats that I had to pull from the Wayback Machine, Netscape Navigator’s JavaScript 1.1
vs Microsoft Internet Explorer’s JScript
. And this is only the start of articles and two books on the subject of cross-browser and cross-version problems. Long before XML, XHTML, CSS and the like. Back in the good old days when we got excited about the FONT tag, and wanted to lynch the idiot that invented BLINK.

I have a set of cross-browser DHTML objects that have successfully ported from the 3.x browsers to working with Mozilla, Netscape 6.x, Opera, and IE 6.x. That’s a lot of time for one set of objects. Want to see them work? Try the Adobe PhotoShop Demos, the Dr. Dotty Games and the very popular Match Game.

Here, I don’t want tech. Here I want everything in the world but tech. Not that I don’t love tech — I do. But I need a break from it. You can get tech at my other web sites. Here, there be nonsense. Unreadable in 3.x nonsense.

Categories
Technology

Kazaa

Recovered from the Wayback Machine.

In reference to the last posting, Julian mentioned that perhaps Kazaa and it’s supernodes have more of an aluminum core because the cloud that supports the Kazaa P2P network is still mallable — 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 a indelible handshake and exchange of signatures that becomes part of the makeup of each circle touched so that one entire P2P circle can disappear, but still be recreated because it’s “genectic” 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 propogate 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 propogated for years. Ask yourselves this — has the fact that the originator of a virus gone offline impacted on the spread of 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 within the internet and ask for directions to points of interest from there.

Standard communication protocol, meta-language, syntax. Viral methods of software and information propogation. 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?

Categories
Just Shelley

Frozen Custard

I’ve been interested in P2P technologies for a few years now. When I was at Skyfish, the former CTO — an Australian by the name of Michael — and I worked out the architecture for a services application that was based on a P2P cloud with absolutely no reliance on a static IP. I constantly preach chaos in the land of the standards. Time for me to spend some serious time on these subjects this week. I’m long overdue. Keep an eye peeled to the TechBlog if any of this interests you.

In the meantime, there’s this blog, which is for all things not technology. For instance…

The doctor said I was very brave today and Robbie said that since I was so good, I would get a treat. A cone of Ted Drewes Frozen Custard — a classic famous round the world. Creamy, subtle, but not too rich. A perfect frozen custard.

The fun part of traveling is finding the sights, scents, and tastes of each place visited. In San Francisco, there’s the crab at the outside vendors at Fisherman’s Wharf, the egg, tomato, and Cobb bacon sandwiches at Farmer’s Market, or the garlic ice cream at the Stinking Rose. In Portland, there’s the micro-brew sampler at McMenamin’s. In New York — hot pretzels from street vendors. Swank in Seattle at the famous Canlis restaurant. Fresh Haystack bread at the Cannon Beach Bakery. Corned Beef and Cabbage at the Black Rose in Boston.

The sinful taste of Boehm’s chocolate covered candied orange. To be accompanied by dark, rich espresso. Drunk out of a mug. A common, cheap, thick, white china mug.

Categories
Just Shelley

Hurt foot

Well, aren’t I deadly dull?

Due to a slight medical problem that has worsened because of my tripping all around the Arch yesterday, I won’t be able to travel for at least a few days while I get additional treatment. I won’t bore you with minute details other than I had an infection in my foot, which hasn’t improved. Well, okay, so I didn’t stay off it like I should — but that’s not the point!

Anyway, I’ll be in St. Louis for a bit longer than originally expected, and conversely, around to pester you all for a few more days before happy trails again.

This really has irritated me, too. Grrr.

IIPM

Categories
Technology

A true P2P Cloud

Recovered from the Wayback Machine.

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.

to be continued…