Changes between Version 1 and Version 2 of RoadMap


Ignore:
Timestamp:
05/07/10 07:45:28 (14 years ago)
Author:
Samuli Seppänen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • RoadMap

    v1 v2  
     1 = Problems with the current codebase =
     2
     3OpenVPN's current codebase has a number of limitations. Some of the limitations require changes to the underlying architecture to be fixed.
     4
     5 == Threads ==
     6
     7Currently, OpenVPN is scaled on SMP machines by adding processes rather than threads.  While it might be interesting to look into scaling OpenVPN across threads, there may be kernel-level bottlenecks that impede this, e.g. note the problems facebook had when trying to scale memcached, specifically the problems of having multiple threads contend for a single UDP socket:
     8  * http://www.facebook.com/note.php?note_id=39391378919&ref=mf
     9
     10 == Monolithic architecture ==
     11
     12The fact that OpenVPN is currently implemented as a monolithic C application makes it difficult to control OpenVPN's internal operation from higher level languages.  Having the core functionality of OpenVPN implemented as a C library would allow it to be wrappable by higher-level language objects more easily. For example, suppose you wanted to build a full-mesh OpenVPN cloud, where OpenVPN runs on hundreds of machines, and where each machine has multiple processors.  It would be much more straightforward to implement the cloud in a high-level language such as python, and wrap the OpenVPN library as a python extension.
     13
     14Another related problem is that OpenVPN's components are not easily exchangable. This means that adding certain types of functionality (e.g. IPv6) or replacing current SSL and compression functionality is much more difficult than it needs to be.
     15
     16 == Event system ==
     17
     18The current non-asynchrous-clean status of the event system makes maintenance of certain OpenVPN components quite tenuous, such as mtcp.c. It might be worthwhile to look into using libevent as the underlying i/o event system for OpenVPN (libevent is used by memcached).
     19
     20 = Rethinking architecture for OpenVPN 3.0? =
     21
     22OpenVPN is essentially a special-case of a user-space network stack.  In future development, OpenVPN could be modularized so that the central core is implemented as a user-space network stack, and the other components such as VPN and routing would be modules in this stack. The above changes make it more straightforward to implement other protocols in the stack, such as IPv6. The network stack changes would also make it much more straightforward to implement alternative topologies for OpenVPN, such as full-mesh. The SSL and compression functionality should be modularized so that OpenVPN can be used with different SSL libraries or different compression algorithms. The current i/o event system needs to be revamped into a true asynchronous model.  While the current event model is partially asynchronous, it is not sufficiently clean to allow certain features to be implemented such as concurrent multithreading or the ability to listen on multiple interfaces simultaneously.
    123
    224
    3  * OpenVPN is essentially a special-case of a user-space network stack.  In future development, it would be interesting to modularize OpenVPN so that the central core is implemented as a user-space network stack, and the other components such as VPN and routing would be modules in this stack.
    4 
    5  * The above changes make it more straightforward to implement other protocols in the stack, such as IPv6.
    6 
    7  * The network stack changes would make it much more straightforward to implement alternative topologies for OpenVPN, such as full-mesh.
    8 
    9  * The SSL and compression functionality should be modularized so that OpenVPN can be used with different SSL libraries or different compression algorithms.
    10 
    11  * The current i/o event system needs to be revamped into a true asynchronous model.  While the current event model is partially asynchronous, it is not sufficiently clean to allow certain features to be implemented such as concurrent multithreading or the ability to listen on multiple interfaces simultaneously.
    12 
    1325 * The current non-asynchrous-clean status of the event system makes maintenance of certain OpenVPN components quite tenuous, such as mtcp.c.
    14 
    1526 * It might be worthwhile to look into using libevent as the underlying i/o event system for OpenVPN (libevent is used by memcached).
    16 
    17  * Currently, OpenVPN is scaled on SMP machines by adding processes rather than threads.  While it might be interesting to look into scaling OpenVPN across threads, there may be kernel-level bottlenecks that impede this, e.g. note the problems facebook had when trying to scale memcached, specifically the problems of having multiple threads contend for a single UDP socket.
    18   * http://www.facebook.com/note.php?note_id=39391378919&ref=mf
    19 
    20  * The fact that OpenVPN is currently implemented as a monolithic C application makes it difficult to control OpenVPN's internal operation from higher level languages.  I would like to see the core functionality of OpenVPN implemented as a C library that would be wrappable by higher-level language objects. For example, suppose you wanted to build a full-mesh OpenVPN cloud, where OpenVPN runs on hundreds of machines, and where each machine has multiple processors.  It would be much more straightforward to implement the cloud in a high-level language such as python, and wrap the OpenVPN library as a python extension.