File-Sharing That Works

Peer-to-peer networking has a serious—don't laugh!—use as a collaborative development tool.

• By Mike Gunderloy
• 10/01/2003

Remember peer-to-peer technology, more familiarly known as P2P? Over the last few years, P2P has followed a parabola that fits right in with the dot-com boom and bust. First came Napster, which splashed P2P all over the public consciousness and spawned a host of imitators (some of which have outlasted their once-proud but sued-out-of-existence parent). Then came a time when every struggling Internet company was going to add P2P features to their products. (“I know! We’ll be the best peer-to-peer banner-ad-driven dog-food sales company on the Net!”) Now that the dust has cleared, most of those projects have vanished, but there’s still a hard core of P2P efforts left—and some of them can be very significant for developers.

No, I’m not talking about file sharing that cloaks copyright violation in a veneer of freedom. Rather, I’m thinking about serious attempts to promote collaboration through software. There are three in particular you might want to look at, from Borland, Microsoft, and Groove.

When P2P Just Works
My first example of useful P2P technology is in a place you might not think to look: Borland’s CodeWright text editor. CodeWright is a high-end programmer’s editor with a $299 price tag; you can learn more about it at http://www.premia.com/. While CodeWright has hundreds of features, I only want to mention one of them here: it’s called CodeMeeting.

What CodeMeeting does is embed a P2P communications layer directly in your text editor. When you enable CodeMeeting, you gain the ability to connect your editing session with that of another user (provided that you can make a TCP/IP connection with their computer). This gives you two things. First, there’s a chat window that opens up so you can communicate by typing. Second, you can share documents. Shared documents can be edited by either user (though only by one user at a time), and changes show up on both computers.

I see CodeMeeting fitting precisely at the intersection of two trends: telecommuting and pair programming. Need to pair with someone who’s not in the office right now? Fire up your copies of CodeWright, load the current source file, and away you go! The simple “pass-the-baton” style of controlling who can edit in the file at any given time fits perfectly with the pair programming paradigm as well. Sure, you won’t have quite the bandwidth typing comments that you would if you were sitting right there and listening to tone of voice (though voice over IP or videoconferencing might offer a nice complement to code-sharing), but you’ll be way ahead of just sending anguished e-mail to the distributed members of your team.

P2P From Redmond
Exhibit B in this particular case is the Windows XP Peer-to-Peer SDK, part of the Windows Peer-to-Peer Networking initiative (you can find out more at http://www.microsoft.com/windowsxp/p2p/). Released in beta form early this year and made final this summer, the Peer-to-Peer SDK offers a set of APIs built on top of the low-level WinSock API. These APIs provide security, peer-to-peer name resolution, replication, and other very low-level services useful in writing P2P applications. Don’t expect to find any finished applications in this SDK; that’s not its purpose. Rather, expect future versions of Windows, as well as applications software from Microsoft and other vendors, to build on top of these APIs.

Interestingly, the P2P APIs defined by Microsoft depend on IPv6, the next generation of TCP/IP, for their network layer. This represents a bit of a gamble on Microsoft’s part, but may pay off if IPv6 takes hold and they already have software out to take advantage of it.

If you’re thinking about P2P applications and want to write on the lowest-level APIs available for performance reasons, this is where you ought to be looking in the Windows world. I would not be at all surprised to find a future version of Windows or Office requiring the installation of these services to enable collaborative scenarios that we can barely envision now.

P2P In the Groove
Microsoft isn’t the only player in the P2P API space for Windows—nor, in my opinion, are they the leading contender. I’d give that crown to Groove Networks. Groove Networks (http://www.groove.net/) are the vendors of the Groove Workspace, a collaborative environment with the slogan “software that effortlessly keeps people, information, and PCs in sync.”

Groove has peer to peer underpinnings, but it’s much more than a simple file-sharing program. To users, Groove is simple: it’s a place to collaborate. That means you can open up Groove on your on machine, create a workspace, and invite other people to join in. Everyone in the workspace can share files, and calendars, and discussions, and other tools. Every user sees Groove as a local application (and, in fact, it replicates data to every computer involved in a workspace). But beneath this local application is an infrastructure that handles such issues as secure communication through firewalls, data compression, and replication with reconciliation.

Like CodeWright, Groove doesn’t especially brag about being P2P. Rather, it concentrates on implementing useful capabilities atop the basic Groove infrastructure. Groove includes tools to do things like collaboratively edit Microsoft Office documents or create outlines or browse the Web together. More importantly from the developer standpoint, Groove includes APIs to let applications from independent vendors take advantage of the Groove infrastructure. You can buy tools in areas such as project management, proposal development, and UML modeling from Groove’s partners. Or, if you like, you can visit Groove’s developer section and learn how to take advantage of these APIs yourself.

Of special note in recent months is the release of the Groove Web Services set of APIs. While the first generation of Groove applications were hosted within the Groove user interface, Groove Web Services provide a standard SOAP-based way for external applications to take advantage of the security, transport, transaction, and other services supplied by Groove for peer-to-peer applications.

So if it’s so great, why isn’t everyone using Groove? So far, they’re suffering from the classic early adopter problem. Networking is great when you can expect everyone you know to have the appropriate software; it doesn’t work well for the first users, unless the people you know are also early adopters. Groove is working to change this by giving away the Preview Edition with enough functionality to be useful, but they have a ways to go before their infrastructure is pervasive. In addition, I’ve found the current Groove software to be somewhat resource-intensive, perhaps because of their use of non-standard graphics widgets. I’ve used Groove for some collaborative projects, and it’s been wonderful—except for the problems of getting other people to install it.

Whither P2P?
If you’ve dismissed P2P as “that file-sharing stuff,” I think it might be time to take another look. What unites the products from Borland, Microsoft, and Groove is the commitment to a P2P fabric as an infrastructure for applications where communication between clients without a server makes sense. This isn’t about circumventing copyrights; it’s about empowering people to work the way that they naturally do. I think we’re headed towards having P2P connectivity be as ubiquitous as TCP/IP or even the telephone dial tone.

In a world of dynamic teams and agile development, the tools that enable people to structure their workload for rapid information sharing and collaboration will be the tools that win in the market. Are you going to be the one who helps write those tools?

Got an idea for a great P2P tool? Or are you ready to just pull yourself off the network and ignore all this stuff? Let me know your experiences either way by e-mail to [email protected]. I’ll use the most interesting comments in a future issue of Developer Central.