I just want to thank you for all the work you are doing and
the excellent support you are providing! The haproxy
project is definitely one of my favourite OSS projects, and
even if the "code was a terrible mess" haproxy is doing a
good job and like Patrick I am looking forward to use it in
more projects, also replacing nginx. I am also looking
forward regarding a better tcp-splicing support, and
recently I was wondering if http://netstreamline.org might
be another way to accomplish it, because the l7-switch
project seems to me a bit abandoned.
Another point that is interesting to me, and most probably to some other people around here as well, is SQL support, and a more modular and flexible future haproxy sounds promising to get more protocols natively supported by haproxy.
Well... enough dreaming ;)
Again, thanks a lot Willy (:
BTW: Last 2 days I tried to access the public interface to the git repo but somehow it looks a bit borked, because I was curios if you merged the trivial build system fix for the PCRE issue. At least it wasn't merged into into the 126.96.36.199. Well, unfortunately I am not able to contribute code at the moment, but I am always willing to contribute back as much as I can in the area of the build system and documentation. So if there are pending ideas or tasks there, do not hesitate to tell me! (:
Mon, 8 Dec 2008 01:20:08 +0100 Willy Tarreau <w#1wt.eu> wrote:
> Hi all,
> for the last few months, haproxy's code was a terrible
> mess. I could finally finish to reorder things and get it
> to work again.
> Its internal structure has changed a bit so that HTTP is
> no longer a hack on top of TCP. Indeed, it was becoming
> increasingly difficult and risky to add even minor HTTP
> features. Several times we unexpectedly broke lower
> layers as side effects.
> Now, the internal structure looks very much like the
> diagrams in buffers.fig. There are several layers which
> can behave independantly :
> layer 7 => eg: HTTP request
> stream protocols (unix, tcpv4, tcpv6)
> file descriptors
> The goal was to be able to easily add new layer7
> protocols or features without breaking the lower layers
> anymore. I would say that this goal is almost achieved.
> I'm saying "almost" because I am not completely satisfied
> with the lower layer, which will still evolve. But at
> least higher layers should not change much.
> Some previous tricks were very easy to implement in the
> new model. For instance, the tarpit is just a protocol
> analyser which does nothing until it reaches its timeout.
> In previous model, it was a state sitting somewhere in
> the middle of HTTP and TCP states. Also, a request or a
> response can now be parsed even with one side shut down,
> which was not possible before, hence the tricks to
> pretend the connection was still open. Also, doing a
> turn-around after a failed connection attempt is
> completely transparent to HTTP now.
> Unix sockets and TCP protocols have converged a lot. Not
> enough yet, but still a lot. Large parts of the code were
> copy-pasted, which is a good sign.
> The stats interface has been cleaned up a bit, and it was
> so much easy to add a new feature that I added the
> session dump command I've been missing during all this
> I've merged all the fixes from the 1.3.15 branch. It's
> very likely that the code still has bugs, but I would say
> that having it that much modular has profundly eased the
> debugging sessions, and I think that it will take less
> time to rule all of them out now.
> I still need to implement the ACLs on the response, which
> was the initial reason to break the old model, and after
> that, I think it will be time to release 1.3.16.
> I'm strongly thinking about making that one the future
> stable release and opening a new development branch,
> because having the development branch being used in
> production everywhere is slowing the development down a
> I've pushed the changes to the git tree. A snapshot will
> be automatically packaged in 3 hours and uploaded there
> so the brave among us can give it a spin :
> I've installed it in front of haproxy's site to ensure
> there's no problem with real-world traffic, so if you
> can't access the site, it probably means I've failed
> somewhere ;-)
> Future features might include DSO loading for layer 7
> protocols, better tcp-splicing abilities, ability to
> chain multiple processings (eg: SSL), the beginning of a
> control socket to set servers up/down, QoS in the request
> queue, and perhaps the beginning of a minimalistic
> keep-alive support.
Received on 2008/12/09 21:07
This archive was generated by hypermail 2.2.0 : 2008/12/09 21:16 CET