Search Slyck  
Interview With DirectConnect's Jon Hess
February 13, 2004
Thomas Mennecke
Font Bigger Font Smaller
DirectConnect, briefly dubbed FileShare, arrived to the P2P scene in November 1999. Since then, DirectConnect has quickly become an important aspect of the file-sharing community. Although this community uses an older networking architecture, the DirectConnect network continues to expand, as its resources exceed FastTrack. We would like to thank Jon Hess, the sole programmer of DirectConnect, for taking the time to participate in this interview.

Slyck.Com: How do you feel about third party clients such as DC++? Do you feel they have enhanced or diminished the Direct Connect network? What, if anything, have you learned from them?

Jon Hess: At first I was very angry. But now I realize clients like DC++ are good for the network. They encourage competition and are the reason I was able to release so many updates of my version 2.0 client this year. At this point I’m flattered by their presence – the anger is gone.

Slyck.Com: Third party clients such as DC++ have included features that many would like to see in the official client such as: single window interface, bandwidth management, less memory usage and a streamlined GUI. Will we see such features implemented into the official client?

Jon Hess: “Single window interface” and “streamlined GUI” have always been features of Direct Connect 2.0. If the last release of Direct Connect that a user has tried was 1.0, they really need to give the 2.2 client a shot.

We briefly had a bandwidth management feature that allowed users to cap their upload bandwidth. Their download bandwidth would be capped at a multiple of the upload cap (8x). I’ve never received so many heated emails about a feature. Many users were upset over it, so we quickly removed it. There is no technical reason the feature isn’t included – the code is written.

Less memory usage is something the other clients are going to beat us on. It’s a trade off, and it’s worth it. Direct Connect is really split cleanly in two sections. We’ve got a c++ back-end and, on windows, a c# front end. The back-end, which is everything direct connect, isn’t actually using much data - usually about 512 kilobytes. The .NET Framework is however a ton of code that has to get loaded into our application’s address space and we can’t avoid that. But we feel all of this is completely worth it. The .NET Framework is best way to program windows applications. It lets us add features much faster than if we were coding to Win32 or MFC.

If there is a feature a user is missing in Direct Connect, we want to know - we aren’t clairvoyant. The best thing users can do is tell us how they feel about the program/ I love reading user reviews of Direct Connect, even the bad ones, as long as they say what is bad.

Slyck.Com: Many feel the Direct Connect network architecture is, by comparison to newer communities, a bit out dated. Is there any chance of introducing multi-source swarming, hashing or connectivity of servers (more like eDonkey2000)?

Jon Hess: There are other more technically advanced networks. And while those network structures may be different and more adept to certain tasks, I think they miss the point. They forget about the user experience and are after files-files-files. Direct Connect is about the user joining communities, not overlay networks. Now, Direct Connect was developed before the concept of swarming was popular. We shouldn’t forget that Direct Connect is probably the oldest file-sharing program on the scene. Swarming is something that we’ve been eying. We may end up implementing the Tiger Tree Hash found in other clients.

Slyck.Com: MetaMachine has introduced Overnet, a decentralized version of the eDonkey2000 network. Are there any prospects of introducing a decentralized Direct Connect network?

Jon Hess: No. That is counter to the nature of Direct Connect. Direct Connect is about hubs. However, Direct Connect shouldn’t be called centralized. There is no one machine that is required for the operation of Direct Connect. Direct Connect is a decentralized network. A hub may seem ‘centralized’ but the fact that there are thousands of them with users bridging all of them makes the network decentralized.

Slyck.Com: What kind of communications, if any, exist between you and the DC++ developers?

Jon Hess: None. However we do speak with users who have switched from DC++ to Direct Connect 2.0 frequently and always want to know how we can make their experience better. We were often viewed as a closed shop in terms of user input, but now users overwhelmingly influence the client’s development. We have an entire section of devoted to user control over the development process (

Slyck.Com: Tell us a little bit about the future of Direct Connect. What features will be implemented to this network/client? Any radical departures from the current Direct Connect philosophy planned?

Jon Hess: Right now the focus is on iterating the development of Direct Connect 2.0. I’d like to see a point release happening bi/tri-monthly. The focus will be on this until users find our client clearly ahead of other Direct Connect implementations. We’d also like to implement the extensions to the network that other developers have included in their applications. I’ve also always wanted to explore more decentralized hubs where multiple hubs can run on many machines and appear to users as a large virtual hub. Honestly though, the road-map isn’t set in stone, and all I can assure users of is that the development will be fast-paced for the rest of the year.

Slyck.Com: Lets talk about the size of the Direct Connect network. The Neo-modus homepage usually states around 200,000 users and 9,000 Terabytes of information (DC++ typically reports more.) How are these numbers calculated, and are they indicative of the entire network?

Jon Hess: We have a tool that profiles the network by periodically visiting the hubs and looking at the user lists of the hubs visited. However, it’s possible that users get counted more than once due to multiple hub connections, and also possible that hubs are never visited due to firewalls or simply being private.

Slyck.Com: Direct Connect development has, at least in the eyes of the P2P community, been slow. How often do you work on Direct Connect? Will the development pace pick up or will maintain the course?

Jon Hess: Direct Connect’s development appeared slow from the summer of 2001 to the summer of 2003 because we dropped Direct Connect 1.0 completely and focused on a rewrite of the core application – Direct Connect 2.0. We released a Mac OS X version, a great operating system if you’re thinking of switching, and ported the Mac code to windows. Now, as a testament to the .NET Framework which many users are unjustly afraid of, I was able to build the Direct Connect 2.0 GUI in 4 months, including the time taken to learn C#. This simply would not have been possible with MFC. Now we have a vastly improved code base and anything is possible.

We may have paid a high start up cost to move to Direct Connect 2.0, but now that we’re here, development is steaming right along. We released more than 20 ‘beta’ builds of the 2.20 client between July and January and there is no plan to slow down.

Like many open source projects, we’ve also split our development into two paths. We have the standard stable build of Direct Connect 2.0 available on the download section along with what we call the latest ‘Weekly Build’. The weekly build is frequently updated, and has all the new features. As the weekly build matures, we slowly roll it over to a stable release and continue the cycle again.

If users would like to participate in the weekly release cycle, they can find everything, including feature suggestion forums and voting at

This story is filed in these Slyck News categories
File-Sharing/P2P Related :: Interviews
P2P Clients :: DC++

You can discuss this article here

© 2001-2019