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

Re: [Openvpn-users] Re: Re: Shared keys vs. certificates performances (a.k.a "the need for speed")


  • Subject: Re: [Openvpn-users] Re: Re: Shared keys vs. certificates performances (a.k.a "the need for speed")
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
  • Date: Mon, 14 Mar 2005 19:29:29 +0000

James Yonan wrote:
> > I must admit that I have been working on a general purpose I/O event
> > library that uses poll/epoll/select, for another application, and it
> > would never have occurred to me to call poll/epoll/select in the first
> > place for a socket which has shown no sign of blocking!
> 
> In some cases, you need to block on write with poll/epoll/select in order 
> to prevent write overruns, for example when TCP sockets are being used.  
> In other cases, an OS could communicate the fact that an internal outgoing 
> UDP queue is full by passing a write-blocking indication to userspace. So 
> it makes sense from a flow-control perspective not to throw away this 
> information.

Yes, flow control is useful, but you don't need to call
poll/epoll/select _until_ the operating system returns EAGAIN on a
UDP/TUN/TAP socket, or a short write on a TCP socket.

The idea is to maintain a flag per socket saying whether the next
write is likely to succeed or return EAGAIN.

After a write to any socket type returns EAGAIN, or after a short
write if it's TCP, you would set that flag.

After a successful write, you would clear that flag.

You would include the socket in the poll/select/epoll set at the next
check only if that flag is set for the socket.  (For epoll you might
optimise further to eliminate calls, but that's complicated to describe).

That gives a nice reduction in system calls while still doing proper
flow control.  Is there a problem with doing this for OpenVPN-style
tunnelling that you know about?

-- Jamie