Active Source Exchange
Active Source Exchange (ASE) 1.0
|
Written By: Kevin O'Toole Edited By: Jonathan C. Nilson |
Status
This proposal is currently not implemented by any client.
Introduction
This proposal addresses the current flaws in the alternate source mesh by not passing on sources that are "old" and client identification for whom to receive sources from. This does not eliminate alternate sources but should make the current system better because it will help keep the mesh (exchange) of sources clean of dead hosts. The proposal has the added benefit of reducing the effects of a Gnutella-style Denial-of-Service attack by reducing the number of bad sources a Shareaza node has, thus keeping that Shareaza node from pestering as many dead sources.
Why is it needed?
ASE removes the need to requery frequently to gather a list of new sources. By sharing only current sources, users will not ...
- get flooded with more dead hosts than live ones
- receive connection attempts for a long time after
- have to clean out a long list of bad hosts
- expericence hangs in the client as frequently
- attempt as many connections on a random port/dynamic IP user
- participte unwittingly in a DoS attack on another user
- requery the network as frequently
- pass a firewalled source to a firewalled client
There are still problems ASE does address but cannot completely solve, which include ...
- hostile clients passing on fake or dead hosts
- hostile clients passing on expired sources
What's different?
ASE changes the way a client chooses which alternate sources to pass and how long each will be active. In effect, a complying client would pass on only active sources in the mesh, each with an expiry time which should be between 10 and 15 minutes. Active sources are defined as sources which have successfully been Queued or Uploading at some time in the last expiry time block (10~15 minutes). This timeout is critical. If clients simply maintain a list, the dead hosts will take longer to populate the ASE, but will still eventually spread and the same problems will occur.
To avoid this fiasco, a client in the ASE passes the address and the timeout (at its current value) to the recipient. This timeout is only reset if the address is successfully contacted and Queued or Uploading before the timeout value expires. Therefore, unless a client sees the source in a successful queue or upload, the address will expire (no matter how many clients have received the source) at the same time. If one client does reset the expiry counter, only sources which receive the source in the ASE subsequently will still have the source. No messages are sent back to clients who have an entry that is about to expire.
If a client wishes to maintain a list of sources that have expired from the ASE, these sources shall not be passed on to subsequent hosts, with or without a timeout. At this point, the sources shall remain knowlegable to the local host alone.
Firewalls
To avoid the propogation of firewalled sources to firewalled clients, each source shall have a header identification indicating the source as a firewalled client which would be sent with the address and timeout. The uploader sends any sources to normal clients, while push sources are not sent to firewalled clients. IANA Reserved IP ranges will not be passed along.
Security
If every client played by these rules, security would be no problem, unfortunately we have to plan for the contingency that we may have hostile, buggy, or poorly-programmed clients. Keeping this system secure would perhaps be a more difficult task than implementing it. Options for achieving this would be either client identification (which can easily be spoofed) or client-to-client authentication. Without client identification or authentication, users run the same risks involved in the alternate-source mesh now.
With client identification security, a user would only receive hosts from chosen vendors (filtered by reported user-agent strings) but still send hosts to any client. This would be a simple solution to the problem if everyone obeyed the rules. Unfortunately, hostile clients such as Qtrax change their user-agent identification to match that of their downloader, which would make the system useless against such clients (fortunately, few exist).
A more complex (perhaps neglible) solution would be client-to-client authentication. Although this should completely solve the problem, it would require a large amount of work for minimal gain, and some valuable alternate sources from unsupporting clients would be lost. This authentication method would, by definition, be closed to only trusted clients, which also defeats the spirit of the Gnutella community. While it solves some problems very well, this course of action is not recommended.
Scenario
To properly illustrate this new system, consider the following scenario. We will assume for the sake of illustration that the expiry threshold is at 15 minutes.
ClientA, ClientB, and Client C all support ASE in its current form. ClientA and ClientB are both downloading File1. Client A knows of the following sources for File1:
111.111.111.1 (Queued 3 of 10 Now) 111.111.111.2 (Downloading Now) 111.111.111.3 (Queued 10 minutes ago) 111.111.111.5 (Downloading Now) 192.168.0.1 (Push) (Never contacted) 0.0.0.0 (Push) (Downloaded 5 minutes ago)
ClientB knows of the following sources for File1:
222.222.222.4 (Queued 20 minutes ago) ClientA (Never contacted)
As ClientB contacts ClientA for the file in question, it refuses to transmit the single known source it has because that source has expired from the ASE. While ClientB may choose to keep that source for its own use, it will not transmit that source to other clients, with or without an expiry timeout.
When ClientA returns the handshake, it transmits a list of ASE sources to ClientB:
111.111.111.1; Timeout=15m 111.111.111.2; Timeout=15m 111.111.111.3; Timeout=5m 111.111.111.5; Timeout=15m; Push
Since 0.0.0.0 is an IANA Private Range, the address is not passed to ClientB, although it is a valid source with a timeout at 10m. 192.168.0.1 is not passed because it has never been contacted.
After ClientB receives this list of sources and is sent a Busy reply by ClientA, ClientB reattempts a connection with 222.222.222.4. This connection results in a successful download. One minute has passed since the ASE list from ClientA was received by ClientB.
ClientC is firewalled, and after searching and finding ClientB as a source for File1, it attempts a connection. Since it has no sources, none are passed to ClientB, however, ClientB passes the same list of known sources to ClientC as ClientA did to ClientB. ClientB also adds its own experience by transimtting 222.222.222.4 because that source is now active and omiting 111.111.111.5 because that is a firewalled source and ClientC is firewalled, so the final list transmitted from ClientB to ClientC is as follows:
111.111.111.1; Timeout=14m 111.111.111.2; Timeout=14m 111.111.111.3; Timeout=4m 222.222.222.4; Timeout=15m
Please note that Timeout values are listed in minutes for the sake of human understanding and will probably be coded in seconds instead.
Conclusion
While this does not solve every problem of the current alternate source mesh, it would be beneficial for anyone who currently uses this system. ASE offers a simple solution to the problems with the alternate source mesh. If implemented on a wide-scale, it could reduce traffic substantially and increase file transfer efficiency tenfold.