Date: Fri, 22 Nov 2002 16:50:16 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Lawson <nate@root.org> Cc: hackers@freebsd.org Subject: Re: Changing socket buffer timeout to a u_long? Message-ID: <3DDED0C8.86D3032@mindspring.com> References: <Pine.BSF.4.21.0211221559460.72334-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson wrote: > This is orthogonal to the original discussion The original discussion was about whether or not to bloat a structure to successfully contain, without overflow, a timer interval stored in ticks instead of a fixed unit. 8-). > but if you had a single > system image, you use the OS to share state just like you share state > between multiple processes on the same machine. The same primitives > work. This kind of misses the point, that applications aren't being written this way, and, short of causing the application to fail when you detect how it's written and don't approve of it (8-)), there's really nothing you can do about this. By the time people need more capacity, the applications are already entrenched. You can't rewrite everything. The easiest way to do this is stateful load-balancing, so that you never violate the applications assumptions about session. > To a lesser degree, a shared directory service gives you the same > thing but requires more application support. Finally, the most difficult > to use as an application programmer is custom, explicit sharing through > writing your own state management protocol or layering it on top of NFS or > LDAP. I understand how to write massively scalable applications; my understanding is not the problem. The problem is incrementally increasing the capacity of an already existing infrastructure which is, itself, inherently non-scalable, by design. Thus, for it to work, you have to deal with things as they are, and not as how they "should be". > > Load balancers and other "MITM" devices are just something you are > > going to have to live with. 8-). > > Yes, but because of the reasons I mentioned before -- closed endpoints > with weak distributed application support. Yep. And until you fix that, which is totally unrelated to FreeBSD, networking equipment, which more and more often *is* based on an embedded FreeBSD core, or at least FreeBSD derived code, for the obvious licensing reasons, needs to not have dumb scalability barriers thrown into its source code for non-technical reasons. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DDED0C8.86D3032>