NEsGUI is a peer-to-peer file sharing application written by Neill Miller in GTK+ which utilizes the NEshare library.
Version: 0.1.5NEsGUI is a peer-to-peer file sharing application written by Neill Miller in GTK+ which utilizes the NEshare library.NEsGUI is a Napster like application. It's one of the simplest and least creative applications utilizing the NEshare peer-to-peer file sharing library.
Operating System: Linux
I started writing NEshare for many reasons. One reason is because I enjoy file sharing with others and I found that there were no true Free Software implementations or designs from the ground up. That's one of the most important reasons to me personally, but I understand it's probably not the reason you're reading this page. Second, I realized that most file sharing implementations that I've played with simply DO NOT WORK well. The one implementation that worked *extremely* well for all of the time I participated in using it was Napster. As for the GnutellaNet (and the like), I tend to have problems with the decentralized nature. This is vague, I know. Specifically, they require an extraordinary amount of bandwidth as compared to a centralized counterpart such as Napster. They tend to generate a lot of garbage since they are responsible for tying themselves to a number of other nodes, which are likewise tying themselves to you. The *only* benefit that I've realized with decentralized networks such as the GnutellaNet is the anonyminity involved. At best, you can see what IP address is downloading or uploading while the upload or download is occuring on your system. Beyond that, there is no record or trace of the transaction and does not involve user names which can be stored or screened, passwords which can be broken or stolen, or any form of user messaging or chat which is prone to SPAM or porn advertisments -- like the sad state of (the oldest widespread and possibly least recognized peer-to-peer system) IRC.
Another reason for writing NEshare is to help you realize that you should not be dependent on a corporation to dictate what you can and can't do with file sharing (a la Napster, FastTrack clients, or any other corporate owned network which you may have become attached to). For example, Napster allowed the sharing of digital music files. Where do you go if you are more interested in sharing original digital pieces of art amongst your friends? What about copies of an ever evolving digital document? Thus, I wanted to provide NEshare to you in case Napster or FastTrack or whatever you use suddenly becomes unavailable, or never suited your needs in the first place. Being Free Software, you're free to modify it and improve it under the terms of the GPL. And if you can't write code, call in a favor from a friend!
NEshare takes the best architectural ideas of centralized networks and mixes them with the best ideas of decentralized networks. It allows anonyminity since there is no messaging system, no username, no password and no record of you once you've left the network. It also works in a reliable manner (minus bugs!) because of the centralized nature. The basic method of transaction is similar to the familiar Napster and FastTrack clients. A user connects to an NEshare server and uploads a file list. The user can search and get results back from the server. Once the results are retrieved by the user, the user connects directly to another user for exchanging files. That's the basic gist of the centralized approach, however the NEshare architecture is flexible and can work in a decentralized manner with relatively little modification if the benefits become more apparent.
One of the biggest advantages of a purely decentralized network (aside from the anonyminity aspect) is the fact that there is no central server which all users must rely on. In the world today, we see the prevention and the hindering of new technologies because big businesses fear to compete. This is wrong. Decentralized networks address this by not allowing a single entity to have complete control over a system. Thus, although threats can be made, they cannot be enforced against all users of a decentralized network. Contrast this with some centralized models - where a corporation takes control of an entire system. They are only pitting themselves against the giants and unfortunately they probably cannot win since (in recent U.S. history at least), Corporations (with cash) suppress our rights (Constitutional, fair rights, whatever) and don't ever look back. Look at the recent headlines regarding the RIAA and Hollywood's general reaction to Napster and other file sharing services. Everyone pounced on Napster and Napster did not survive. Sure, the company may still have a vision for itself, but everything that you and I enjoyed about the service is gone. The vision we've created for it is gone. I haven't used Napster since late 2000.
I'm not advocating using this software for actions which are questionably legal. I'm providing this software for educational reasons because I believe that there is a lot to learn about networking applications and we've only seen the tip of the iceberg. This software has many legitimate uses such as online collaboration on any number of projects, sharing original works or documents, browsing which new Free Software packages are available amongst your peers, learning how a multi-threaded server works, learning how to use sockets, seeing an example of how a network protocol can be written from scratch, congesting your local network for bandwidth experiments and measurements, etc. The uses are endless. And the uses are legitimate. This software may help other to find something new. This software may *be* something new to others. Whatever the case, it's all about vision.
By designing a Free Software implementation of a peer-to-peer protocol, I'm offering it to you to suit your vision. I don't want to see one central server out there that everyone connects to for whatever use. I want to see the decentralization of the centralized model. I want to see something like what happened to the webserver to happen to NEshare. Each person that is interested in this kind of project should run and manage their own server for their own intranet. Choices are good. Although NEshare is centralized right now (like a webserver) -- wouldn't it be a horrible thing if all information on the web was hosted on the same server? This is what Napster tried to acomplish. They took the centralized server a little too far to prevent people like you and me from having our own visions and creative uses for the technology. NEshare should work differently. For example, if you look at streaming radio servers -- these are central servers all over the place which have several central resources (i.e. webpages) which tell you about which ones are available and their current status. This feature is planned for NEshare, although the first release of the server will have to be tracked manually if you'd like to advertise your server to others.
I'd like to add that I do believe that decentralized networks inherently have some cool ideas behind them, so I did not exclude the possibility of NEshare working in a fully decentralized manner. The first version that I'm working on will be only centralized, but decentralization is an option since it should not prove to be too difficult given the architecture. However, since in my experience the fully decentralized network tends to have more issues than benefits, I would like to keep NEshare centralized. Again, a decentralization of the centralized model would be ideal.
The other major design goal of NEshare is to make it a toolkit. What I mean by this is that currently, there is a client library which can readily be dropped into an application of any kind. This means that for developers who are working on applications, if peer-to-peer file sharing would be useful, it can be easily used under the terms of the GPL inside of their own applications. This also makes for a more lightweight graphical user interface, since the bulk of the work is inside the client library. In order for all of NEshare to work in a purely decentralized manner, the work of the server must be integrated into the client library and a few new messages will need to be developed so that it can act as a servent. The architecture is rather flexible, and this will remain a design goal moving forward.
Needless to say this takes a lot of work. I'm a single hacker at best and I've been working on this project in free time since the summer of 2001. I can only do so much, and I'm limited by my imagination and programming skills. That's why I need your help. So far, my work consists of designing the networking protocol capable of accomplishing file sharing in a peer to peer manner, implementing this protocol in code, testing the code, improving the code, etc. I can't do this by myself (although unfortunately so far I have been and will continue to if no one volunteers). I would appreciate help in the areas of testing, documentation, and of course good old fashioned hacking. If this project sounds interesting to you, feel free to contact me.
What's New in This Release:
· Code now honors the std namespace so that it's gcc-3.x compatible
· Fixed some event handling that caused erroneous message boxes to appear
· Better unexpected peer disconnection handling
· Added proper ChangeLog entries