5 | | OpenVPN's current codebase has a number of limitations. Some of the limitations require changes to the underlying architecture to be fixed. |
| 5 | OpenVPN's current codebase has a number of limitations. Some of the limitations require changes to the underlying architecture to be fixed. Roadmap issues and relationship of OpenVPN 2.x series and 3.0 have been discussed earlier in a few IRC meetings: |
| 6 | |
| 7 | * [http://thread.gmane.org/gmane.network.openvpn.devel/3447 1st Apr 2010] |
| 8 | * 21:36 - 21:47: James' plans for 3.0 |
| 9 | * 21:59 - 22:09: Multithreading and the event system |
| 10 | * [http://thread.gmane.org/gmane.network.openvpn.devel/3525 15th Apr 2010] |
| 11 | * 14:28 - 14:31: Roadmap using Trac |
| 12 | * [http://thread.gmane.org/gmane.network.openvpn.devel/3673 29th Apr 2010] |
| 13 | * 22:23 - 22:53: Planning of the roadmap meeting |
| 14 | * 6th May 2010 |
| 15 | * The roadmap meeting. James' views available here |
20 | | The current non-asynchrous-clean status of the event system makes maintenance of certain OpenVPN components quite tenuous, such as mtcp.c. 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. To get these features the current i/o event system needs to be revamped into a true asynchronous model. It might be worthwhile to look into using libevent as the underlying i/o event system for OpenVPN (libevent is used by memcached). |
| 32 | The current non-asynchrous-clean status of the event system makes maintenance of certain OpenVPN components quite tenuous, such as mtcp.c. 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. The limitations of current event system are also closely tied to OpenVPN's lack of multithreading. To get these features the current i/o event system needs to be revamped into a true asynchronous model. It might be worthwhile to look into using libevent as the underlying i/o event system for OpenVPN (libevent is used by memcached). |
| 33 | |
| 34 | = OpenVPN 3.0: Start from scratch or incremental approach? = |
| 35 | |
| 36 | == Technical considerations == |
| 37 | |
| 38 | Some of the |
| 39 | |
| 40 | == Organic vs. planned development == |