On Fri, 2010-03-05 at 09:01 +0100, Gert Doering wrote: > Hi, > > On Thu, Mar 04, 2010 at 05:21:43PM -0600, open...@rkmorris.us wrote: > > I did this in the client configuration file ... is this right? > > I checked the OpenVPN web site, and it may be that I need this on > > the server side instead. Please clarify and I'll try it again (if > > I need to). > > "socket-flags TCP_NODELAY"
> that would need to go into both(!) config files - it changes the way the > operating system handles write() calls into a socket, that is, whether > the OS waits for "more data" to eventually generate a full sized packet, > or whether it will send the data immediately (generating a small packet). > (This is a fundamental problem with TCP - the stacks are optimized for > certain patterns, either "bulk data, make full size packets" or > "interactive traffic, send single bytes of keystrokes, where a few ms > delay don't hurt", but not for VPN-like traffic) Oh WOW... I hadn't even thought of that. That's got to be the A #1 reason right there for avoiding the use of tcp like the plague for things like these. That means that OpenVPN is (to use the older terminology - I'm old school) not using the PUSH OOB method to push packets out and to get them received immediately at the other end. Looking that the socket_write calls, that would seem to be the MSG_OOB option. I use to remember in days ancient using TCP_URGENT and TCP_PUSH flags for things like that (TCP_URGENT was used by ftp clients to abort interrupted data streams). All I see in socket.h is "MSG_NOSIGNAL". Yeah, that would probably do it. TCP_NODELAY is going to disable the naggle algorithm and disable the send buffering but I don't think it's going to set the TH_PUSH flag in the tcp header so what the received side does with it is up to the received side, isn't it? Yeah, I know, PUSH is an optional feature in tcp implementations but it's been in every one I've worked with and I see the comments about it having it's own problems. But how in the world would anyone expect a user space packet handler to work efficiently over tcp STREAMS without it? You've got to work around tcp's design to treat everything as a continuous stream and to optimize it as a stream and not a series of packets. If nothing else, I would always expect tcp vpn's the suck royally without at least having TCP_NODELAY. Why isn't that the default. http://www.unixguide.net/network/socketfaq/2.11.shtml > gert Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
