Tag: P2P

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
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…

Categories
Technology

Emerging Technologies Conf

Recovered from the Wayback Machine.

Dave mentioned today that he’ll be giving a presentation at the Emerging Technologies Conference.

My conference proposal was rejected, which was disappointing — particularly since the session I gave at the first P2P conference was successful. Such is life.

So if you’re going to the conference you can see Dave, but you’ll miss the following session:

====================

Proposal Information

====================

Title: Smart Web Services

Conference: O’Reilly Emerging Technology Conference 2002

Type: Paper

Duration: 45m

Audience Level: Experienced

Audience Type: Session is geared towards developers, technology architects, and other technology practioners.

Preferred Date: All

Description:

How’s this for a product: you put it out on the street, and it goes out and finds the customer rather than waiting for the customer to find it.

Web services are handy, but they’re passive and not all that smart. What’s missing in their basic implementation is other functionality such as web service events, transaction management, security, service discovery, verification, as well as service identification.

In particular, web services sit passively waiting for a client to discover them, through UDDI or other publication processes.

This session takes a look at one aspect of smarter web services — service discovery and identification. In particular it looks at the use of Resource Description Framework (RDF) in addition to other technologies to create services that that can actively market themselves. Borrowing from the efforts associated with the semantic web and intelligent agents, in addition to the decentralization research of P2P, these services can then seek out the client, rather than waiting for the client to seek them.

Actual demonstrations of both technology and concepts will be provided in the session.

Categories
Technology

P2P for Radio

Recovered from the Wayback Machine.

When I return from vacation land, I’m going to build a true P2P cloud for Radio. I’ve been wanting to test some functionality and needed a good user-interface vehicle. Looks like Radio is a good fit.

I need a golden gateway, but I imagine Userland would provide the server space for that.

One nice thing about long drives, you have a lot of time to think of new and interesting things. Unfortunately, this can lead to driving frantically across 6 lanes of fast and crowded California freeway because the I5 split was to the left, not the right. California drivers are very cool, and made space for my mad manuever.

Or was it just being smart?

Categories
Web

What the hell is P2P?

Recovered from the Wayback Machine.

If the Net is good for one thing, it’s the propagation of buzzwords and acronyms. In the case of P2P – Peer-to-Peer – you have a term that is both buzzword and acronym, and represents a group of technologies that is both very old (in Net terms) and very new.

Well, that’s all fine and dandy, but what the hell is P2P?

Well, some (such as Clay Shirky of The Accelerator Group) would say that P2P technologies encompass any technology that exists outside of DNS. Sounds impressive, but what does this mean?

This means that P2P services are accessed using some technique other than Domain Name Service (DNS) lookup. DNS is used to find specific IP addresses using well-known and human friendly aliases such as www.w3.org. P2P doesn’t rely on DNS and aliases such as these because much of the P2P resources and/or functionality may exist on IP addresses that change every time a participant connects to the Net through something such as a dial-up modem.

Tim O’Reilly broadens P2P to include any technology whereby peers share services and/or resources rather than these same resources being served up by a central server. In addition he also includes collaborative functionality and distributed computing, as well as instant messaging services such as AOL’s Instant Messenger and Jabber. In each of these, common points of intersection are features such as an assumption of no fixed IP address and no reliance on a common, centralized server.

Based on this, a standard Web application is not P2P because clients that access a site’s functionality all do so through one common server – the Web server – using a well-known DNS-supplied and supported name. Though the approach is Net-enabled, this way of serving functionality is a variation of the standard client/server application model that’s been around for years, with the browser acting as what is termed a very thin client (i.e. very little of the functionality is present on the client, most resides on the server).

So, if Web browsing isn’t P2P, how does P2P work?

As an example of P2P in action in its purest form, Gnutella is a P2P application that enables file and resource sharing among peers.  To participate, you download the Gnutella client software, you pick an IP address among any that are currently connected to the system and connect to that IP, or connect to several IPs of friends and known associates who are also Gnutella clients.

Once connected to the Gnutella network, you have access to the peers each of your connected IPs are connected to, and through these secondary connections you have access to their connections, and so on. Sort of like a phone tree where the phone numbers change every day, but you’re guaranteed to have access to at least one of the numbers at any given time.

What happens once you’re connected? Well, in the case of another known P2P application, Freenet, you can issue a request for a specific file or resource, and any client that has access to that resource returns it via the request path…to you.

Gnutella and Freenet share the same common characteristics of P2P applications. Both use a naming system other than DNS to locate peers; both don’t require a common, centralized server. However, they differ in that with Freenet, each peer along the request path could keep a copy of the resource requested, basically increasing its availability. The more times a resource is accessed, the more peers have the resource on their own machines, the easier it is to access the resource.

With Gnutella, only the original resource and you since you’ve now accessed this resource have access to it. Because of this, you’re less likely to find the resource you’re requesting because it’s out of range of your request, or beyond the horizen. (Your request, unlike the ghost ships of yore isn’t going to float about the Internet, unsatisfied, forever. It will time out at a certain point.).

(Andy Oram has an excellent article on Gnutella and Freenet at http://www.oreillynet.com/pub/a/network/2000/05/12/magazine/gnutella.html.)

Okay, so that’s a quick look at some of the more well known P2P applications (other than Napster, and I’m sick of hearing about Napster). So now you might be asking yourself why you would care about this type of technology? Especially in a business context? After all, how can you charge for something when there’s no centralized server and no way of knowing which peer is accessing what resource?

Going back to Tim O’Reilly’s original list, let’s take a look at the concept of collaboration. In a collaborative P2P application, a group of peers work together on a specific project, such as a document or a presentation or using a virtual white board to brainstorm. In this type of environment, the services to work on the collaborative project are located on the peers, and the data is propagated to each of the clients at set intervals (based on the type of collaborative effort and the infrastructure supporting the peers). Again, there doesn’t have to be set IP addresses (though there isn’t a prohibition against fixed IP address), and there doesn’t have to be a central server (though again, a central server could be used to do such things as backup group data periodically – as long as it isn’t essential to the application process). In fact, a hybrid P2P application can be one that uses a centralized server for IP lookup, but all other services are performed on the peers.

It would be safe to say that this type of application does have commercial possibilities, and it is this type of technology that’s currently being implemented within the Groove architecture, a framework and toolset as well as application created by Ray Ozzie of Lotus Notes fame.

(You can download Groove at http://www.groove.net.)

How viable is something such as Groove? Viable enough to warrant 60 million dollars of Venture Capital money, and that’s big bucks to folks like you and I.

How Groove works is that a person wanting to be a peer downloads the Groove application/infrastructure and installs it on his or her machine. The architecture supports a user interface that provides a working area, known as a shared space,  for the collaborative efforts supported by the application.

A shared space could contain something as simple as a discussion forum, a virtual white board, or a chess game; or it could contain functionality as complex as a piece of a sophisticated supply chain application.

The Groove architecture provides the infrastructure to support tools that can be used in the shared spaces, and vendors can provide Groove “connectors” for their existing applications, or can create new tools for Groove, through exposed interconnectivity accessed through the Groove Developer Kit (GDK).

So, if a major player such as Ariba wanted to publish their software services through Groove, they can by using the GDK to create a Groove tool that acts as a connector to the company’s services. By doing this, Ariba then gets the benefit of an architecture that supports safe, secure, efficient, and multi-peer access of its applications without having to write more than some XML files, and perhaps a COM/COM+ wrapper (if the Ariba service isn’t currently implemented as a COM service – Groove’s current service implementation).

(See more on the Groove architecture at http://www.groovenetworks.com and download the Groove Developer Kit at http://devzone.groove.net. See more on Ariba at http://www.ariba.com.)

How will Ray Ozzie make money with Groove? By licensing the Groove architecture to these third party service suppliers, who in turn, license their services to the peer – the customer wanting access to the services.

Making money. Sounds good.

(See an article “21 for 2001” from internet.com at http://boston.internet.com/views/article/0,1928,2011_552841,00.html that looks at 21 startup companies in Boston this publication believes will succeed in the year 2001. Features Groove)

A company can use P2P-friendly technologies, while still staying within more conservative, mainstream client-server types of implementation, such as browser-based access. For instance, speaking of Ariba earlier, this is a company that is using technologies that would enable this company to become P2P-abled fairly easily, if the company chooses.

As an example of P2P-friendly technologies, Ariba is partnered with webMethods, a leading integration application software company that provides a centralized “hub and spoke” technology to allow different companies’ heterogeneous applications to communicate.

(See more on webMethods at http://www.webmethods.com. More on the products at http://www.webmethods.com/content/1,1107,SolutionsIndex,FF.html.)

Ariba supports a dialog of XML (another buzzy acronym that turned everything upside down) called cXML – Commerce XML – within its Ariba Commerce Services Network (CNS) architecture. This architecture, in turn, supports many of the popular eMarket and B2B Ariba applications such as Ariba MarketPlace or Ariba Buyer.

To support integration with clients, all transactions within the CNS architecture are based in cXML, and webMethods has provided a cXML interface within its own set of integration applications. As webMethods supports interfaces to numerous other XML-based languages such as RosettaNet and numerous other technologies, clients can access the Ariba CNS services through the webMethods supplied cXML interface, using their own application-specific technology (and legacy systems – no major re-write required).

So a buyer can use Ariba CNS services to access a catalog item and purchase an item, and have the process connect seamlessly to the supplier applications created using something such as EJB (Enterprise Java Beans) through the webMethods integration interfaces.

Now, technically, all of this in dependent on a server being in place (the CNS services and the webMethods hub), but the infrastructure is such that it wouldn’t take a major re-engineering effort to lighten and split apart the services to form a P2P network. And Ariba and webMethods would still lease or sell their individual services – integrated licensing could prevent any individual from sending copies of these services out freely on the Net for anyone to use.

There’s that making money again.