On Fri, 2010-03-05 at 09:42 -0500, Michael H. Warfield wrote: > 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. Looking at the man page on tcp is appears that MSG_OOB applies the TCP_URGENT semantic to the stream, not the TCP_PUSH. That would also entail a SIGURG signal on each packet on the receiver side. Maybe not such a good thing on every packet after all, even if you set that to SIG_IGNORE. :-P > 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 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
