[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Hibernation question


  • Subject: Re: [Openvpn-users] Hibernation question
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Mon, 13 Dec 2004 15:25:47 -0700 (MST)

On Mon, 13 Dec 2004, Steven Palm wrote:

> 
> First, thanks for finding the problem. Not that it will do any good, 
> but I can submit a request through to Apple to implement and prefer the 
> poll() method over select().  :-)

Both poll and select are fairly old syscalls, and select in particular is
rather badly designed from an efficiency and scalability perspective, but
even poll is not much better if the number of waited-for events grows
large.  But poll is good enough for almost everything OpenVPN does except
for the --mode server --proto tcp-server event loop.

Unfortunately, no one was able to make a scalable version of poll or 
select early enough that it would have stuck as a standard on all the 
major OSes, in the same way that all the major OSes today support (with 
minor differences) the Berkeley sockets API.

So this is an area where the lack of early agreement caused the major OSes 
to go off and implement their own incompatible APIs for doing event waits 
in a scalable way.  Linux has epoll, the BSDs have kevents, etc.

OpenVPN tries to abstract away all this OS incompatibility by using a 
consistent interface internally (see event.[ch]) but then at a lower level 
using poll, select, or whatever works best on the underlying OS.

I'm not sure what OS X has in this venue, but I recall that given poll or
select, select was to be preferred (which is unfortunate since select is
more inefficient).  It's possible that OS X has a better function than
either select or poll (kevents perhaps? -- this is generally the BSD
solution to a scalable event wait API).

If so, it might be useful if someone wanted to step forward and do a 
kevents driver in OpenVPN's event.[ch].

> Secondly, I see that it was just a misunderstanding on my part but I'm 
> wondering which is more logical...
> 
> If I start openvpn with hold on, it requires a hold release to start. 
> Very good, this makes perfect sense.  However, if I issue a "hold off", 
> that turns off holding, but it doesn't make it start if it was in a 
> hold state.  Is that right?  My initial thought was "turn hold off" and 
> let it go as well as not needing to do it again upon a signal restart.  
> Not a huge issue, I'll adjust my command sequence accordingly, but I 
> thought I'd mention it for discussion/consideration based on what may 
> be more logical. (Not that I always am.... ;-)

Yes, I wanted to logically separate the hold flag (controlling whether we
should hold on the next restart) from the current hold state (are we 
holding right now).

hold on/off changes the hold flag.

hold release gets us out of a holding state.

If you want to clear the hold flag and get out of the current holding 
state, you should do:

  hold off
  hold release

If you want to keep the hold flag set, so that the next restart will also 
hold, but you want to get out of the current holding state, then simply:

  hold release

James

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users