On 08/08/14 03:24, Jan Just Keijser wrote:
> I would also opt for function handlers/pointers per connection - that
> way you could server both udp+tcp from a single server instance
Yes - having one server instance managing both udp and tcp AND being
able to handle multiple ports should be part of
On 07/08/14 16:15, Les Mikesell wrote:
> On Thu, Aug 7, 2014 at 4:56 AM, David Sommerseth
> wrote:
>> However, that is most likely less intrusive and complex than to
>> basically needing to re-write the event handler which schedules that
>> each client gets their "time slice" in OpenVPN. OpenVPN'
On Thu, Aug 7, 2014 at 4:56 AM, David Sommerseth
wrote:
>
> However, that is most likely less intrusive and complex than to
> basically needing to re-write the event handler which schedules that
> each client gets their "time slice" in OpenVPN. OpenVPN's event
> handling the only thing which make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/08/14 22:52, Les Mikesell wrote:
> On Wed, Aug 6, 2014 at 3:36 PM, David Sommerseth
> wrote:
>>
>>> For the typical road-warrior scenario (one server, many
>>> clients) you are probably right that a single user won't
>>> benefit much from data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/08/14 00:37, Jason Haar wrote:
> On 07/08/14 00:12, David Sommerseth wrote:
>> What is CPU intensive is when asymmetric encryption comes into
>> play, with the key exchanges and other negotiations etc.
>
> I sooo have to agree with that. Back in
On 07/08/14 00:12, David Sommerseth wrote:
> What is CPU intensive is when asymmetric encryption comes into play,
> with the key exchanges and other negotiations etc.
I sooo have to agree with that. Back in the day I could notice even with
only TWO clients how openvpn would completely HANG durin
On Wed, Aug 6, 2014 at 3:36 PM, David Sommerseth
wrote:
>
>> For the typical road-warrior scenario (one server, many clients)
>> you are probably right that a single user won't benefit much from
>> data-channel threading. However, in a high-capacity site-to-site
>> link, many concurrent connection
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/08/14 22:20, Steffan Karger wrote:
> Hi Joe,
>
> On Wed, Aug 6, 2014 at 10:06 PM, Joe Patterson
> wrote:
>> The only disadvantage I see is that it does prevent a single
>> client from being able to be serviced by multiple cores, but if
>> I'm n
Hi Joe,
On Wed, Aug 6, 2014 at 10:06 PM, Joe Patterson wrote:
> The only disadvantage I see is that it does
> prevent a single client from being able to be serviced by multiple cores,
> but if I'm not wrong that's going to be a problem whether it's threaded or
> multi-process, unless you're using
Hi,
On Wed, Aug 06, 2014 at 04:06:58PM -0400, Joe Patterson wrote:
> I still maintain that it would be much simpler and more useful to put less
> effort into making a multi-threaded process, and more effort into making it
> easier for multiple processes to coordinate amongst one another.
Feel f
I still maintain that it would be much simpler and more useful to put less
effort into making a multi-threaded process, and more effort into making it
easier for multiple processes to coordinate amongst one another. That gets
the advantage of more easily being able to allocate multiple clients acr
On 08/06/2014 02:38 PM, David Sommerseth wrote:
> On 06/08/14 15:20, Gert Doering wrote:
>
>>> What is CPU intensive is when asymmetric encryption comes into
>>> play, with the key exchanges and other negotiations etc.
>
>> slow, but used much more seldom... assuming VPN clients that stay
>> co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/08/14 15:20, Gert Doering wrote:
>> What is CPU intensive is when asymmetric encryption comes into
>> play, with the key exchanges and other negotiations etc.
>
> slow, but used much more seldom... assuming VPN clients that stay
> connected f
Hi,
On Wed, Aug 6, 2014 at 3:20 PM, Gert Doering wrote:
> On Wed, Aug 06, 2014 at 02:12:12PM +0200, David Sommerseth wrote:
>> The encryption and decryption using symmetric keys are really fast.
>
> fast, but used very very often...
Yes, and less difficult to separate. That is why I would tackle
Hi,
On Wed, Aug 06, 2014 at 02:12:12PM +0200, David Sommerseth wrote:
> Just thinking aloud now, without many filters enabled. (read: uh-oh!)
:)
> The encryption and decryption using symmetric keys are really fast.
fast, but used very very often...
> What is CPU intensive is when asymmetric en
On Wed, Aug 6, 2014 at 7:12 AM, David Sommerseth
wrote:
>
> With this in mind, it does make sense to split out the asymmetric
> encryption phases to a separate core, which can allow other symmetric
> encrypted traffic to flow more freely.
>
> But, this is just splitting stuff into 2 threads. Any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/08/14 11:34, Gert Doering wrote:
> Hi,
>
> On Tue, Aug 05, 2014 at 03:21:39PM -0500, Les Mikesell wrote:
>> I don't know enough about the rekeying process to know it this
>> is feasible, but it seems like there should be a way to use
>> somethin
Hi,
On Tue, Aug 05, 2014 at 03:21:39PM -0500, Les Mikesell wrote:
> I don't know enough about the rekeying process to know it this is
> feasible, but it seems like there should be a way to use something
> like apache's prefork model to spin off some number of processes to do
> the cpu-intensive pa
On Tue, Aug 5, 2014 at 12:27 AM, Gert Doering wrote:
>>> >
>> > This is a complex problem. You need a programmer that understands
>> > parallel processes or threads, network, security, and is willing to
>> > spend quite a bit of personal time on it - implementation, code review,
>> > testing.
>>
So maybe what's really needed is less having multi-threading support within
a single openvpn process, but more adding some functionality that makes it
easier to get to the desired end-state, like extending the ip persistence
from a flat file to perhaps a database connection, and have a way to defin
On 05/08/14 04:43, Gert Doering wrote:
> Hi,
>
> On Mon, Aug 04, 2014 at 11:24:28PM +0200, Mathias Jeschke wrote:
>> You should think about starting a crowdfunding campaign ;)
> This is an interesting idea.
>
> It's not going to happen "soonish" (next thing is 2.4, which should see
> the light of d
Hi,
On Mon, Aug 04, 2014 at 11:24:28PM +0200, Mathias Jeschke wrote:
> You should think about starting a crowdfunding campaign ;)
This is an interesting idea.
It's not going to happen "soonish" (next thing is 2.4, which should see
the light of day in the the next few months), but maybe after tha
Hi,
On Tue, Aug 05, 2014 at 12:00:53PM +1200, Jason Haar wrote:
> On 05/08/14 08:36, Gert Doering wrote:
> > "Nobody did the code yet".
> >
> > This is a complex problem. You need a programmer that understands
> > parallel processes or threads, network, security, and is willing to
> > spend qui
On Mon, Aug 4, 2014 at 5:24 PM, Mathias Jeschke wrote:
> On 08/04/2014 10:36 PM, Gert Doering wrote:
>
>> Pay me for about 6-8 weeks, and I think I can do it... but in my copious
>> spare time, I won't even start this, as it's too complex a task.
>
> You should think about starting a crowdfunding
On 05/08/14 08:36, Gert Doering wrote:
> "Nobody did the code yet".
>
> This is a complex problem. You need a programmer that understands
> parallel processes or threads, network, security, and is willing to
> spend quite a bit of personal time on it - implementation, code review,
> testing.
I t
On 08/04/2014 10:36 PM, Gert Doering wrote:
> Pay me for about 6-8 weeks, and I think I can do it... but in my copious
> spare time, I won't even start this, as it's too complex a task.
You should think about starting a crowdfunding campaign ;)
Mathias.
Hi,
On Mon, Aug 04, 2014 at 08:02:32PM +, Goofy wrote:
> I think it will be fine to have multiple core support.
> I belive it is beneficial when you reboot your Server and
> more than 200 VPN connections will be re-connected ?
Indeed, it would be great.
> And all new Hardware have multi core
I think it will be fine to have multiple core support.
I belive it is beneficial when you reboot your Server and
more than 200 VPN connections will be re-connected ?
And all new Hardware have multi core support why should openvpn not use this ?
Goofy
---
28 matches
Mail list logo
