Difference between revisions of "ECv2"

From AMule Project FAQ
Jump to: navigation, search
m
Line 7: Line 7:
 
The necessity to redisign the [[External Connections]] code came from a security hole a user reported and had to be quickly patched. After fixing it, it became obvious that the protocol's design wasn't flexible, secure and fast enough to have it as a standard protocol for any future application trying to connect to [[aMule]].
 
The necessity to redisign the [[External Connections]] code came from a security hole a user reported and had to be quickly patched. After fixing it, it became obvious that the protocol's design wasn't flexible, secure and fast enough to have it as a standard protocol for any future application trying to connect to [[aMule]].
  
The main goal of this protocol is to make it binnary (up to now, it was strings-driven) and to enforce it's security. Apart from that, many care has been taken in make it as fast and flexible as possible. It has become so complex that it can now be considered an [http://en.wikipedia.org/wiki/Application_layer Application layer] (in the [http://en.wikipedia.org/wiki/OSI_model OSI model]).
+
The main goal of this protocol is to make it binnary (up to now, it was strings-driven) and to enforce its security. Apart from that, many care has been taken in make it as fast and flexible as possible. It has become so complex that it can now be considered an [http://en.wikipedia.org/wiki/Application_layer Application layer] (in the [http://en.wikipedia.org/wiki/OSI_model OSI model]).
  
 
The new protocol's design specification can be found in the docs that come along with the [[aMule]] tarball.
 
The new protocol's design specification can be found in the docs that come along with the [[aMule]] tarball.

Revision as of 19:04, 4 January 2006

ECv2 stands for External Connections 2.0.

It is a complete rewrite of the old External Connections code, mainly designed by GonoszTopi with help from phoenix and lfroen.

This new version (starting from aMule 2.0.0-rc8) is incompatible with any previous version.

The necessity to redisign the External Connections code came from a security hole a user reported and had to be quickly patched. After fixing it, it became obvious that the protocol's design wasn't flexible, secure and fast enough to have it as a standard protocol for any future application trying to connect to aMule.

The main goal of this protocol is to make it binnary (up to now, it was strings-driven) and to enforce its security. Apart from that, many care has been taken in make it as fast and flexible as possible. It has become so complex that it can now be considered an Application layer (in the OSI model).

The new protocol's design specification can be found in the docs that come along with the aMule tarball.