Re: Quick Response
Hi, Just wanted to follow up on my previous email to see if you've had a chance to look into it yet. I'm really looking forward to hearing back from you soon! Thanks, Jessica Subject: AWS Users Business Leads. Hi there, I just wanted to check if you' d be interested in obtaining the contact list of Amazon Web Services Users for your sales and marketing initiatives. We also have related technology users like: Microsoft Azure, Google Cloud Platform, Oracle Cloud, Salesforce, VMware, Huawei, Tencent Cloud, Rackspace and more... Just let me know your target audience and geography (USA, UK, Canada...) and I can quickly provide you with counts and pricing information. We are running 3rd Quarter specials (flat 40% off on any list purchase). Shoot me any questions you may have as well-I'm here to help! Regards, Jessica Lesa Sr. Marketing Manager To opt out please response No.
Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC
Yes, what are the next steps? I updated my test PR with the latest changes from HAProxy master and it is still passing [1]. With a cached AWS-LC build the HAProxy build + test takes 2 minutes. Attached are the updated patch files, I can also combine them since they’re both small. For the defines: we already have OPENSSL_IS_AWSLC and I agree that’s reasonable to use if there is a spot we need to branch on, but the goal is not to need it. For the OPENSSL_VERSION_NUMBER we are currently not 100% 1.1.1 API compatible, we are working to improve that so other projects can easily migrate. [2] will make the version string behavior match OpenSSL’s. We are compatible for HAPRoxy’s current use of OpenSSL after [3], [4], [5] were merged in. [1] https://github.com/andrewhop/haproxy/pull/1 [2] https://github.com/aws/aws-lc/pull/767 [3] https://github.com/aws/aws-lc/pull/1032 [4] https://github.com/aws/aws-lc/pull/1055 [5] https://github.com/aws/aws-lc/pull/1070 From: Илья Шипицин Date: Wednesday, August 9, 2023 at 11:26 PM To: William Lallemand Cc: Willy Tarreau , "Hopkins, Andrew" , Aleksandar Lazic , "haproxy@formilux.org" Subject: RE: [EXTERNAL] [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. shall we unfreeze this activity? вт, 18 июл. 2023 г. в 10:46, William Lallemand mailto:wlallem...@haproxy.com>>: On Tue, Jul 18, 2023 at 09:11:33AM +0200, Willy Tarreau wrote: > I'll let the SSL maintainers check all this, but my sentiment is that in > general if there are differences between the libs, it would be better if > we have a special define for this one as well. It's easier to write and > maintain "#if defined(OPENSSL_IS_BORINGSSL) || defined(OPENSSL_IS_AWSLC)" > than making it appear sometimes as one of them, sometimes as the other. > That's what we had a long time ago and it was a real pain, every single > move in any lib would cause breakage somewhere. Being able to reliably > identify a library and handle its special cases is much better. I agree, we could even add a build option OPENSSL_AWSLC=1 like we've done with wolfssl, since this is a variant of the Openssl API. Then every supported features could be activated with the HAVE_SSL_* defines in openssl-compat.h. Discovering the features with libreSSL and boringSSL version defines was a real mess, we are probably going to end up with a matrix of features supported by different libraries. I'm seeing multiple defines that can be useful in haproxy: - OPENSSL_IS_AWSLC could be used as Willy said, that could enough and we maybe won't need the build option. - OPENSSL_VERSION_NUMBER it seems to be set to 0x1010107f but is this 100% compatible with the openssl 1.1.1 API? - AWSLC_VERSION_NUMBER_STRING It seems to be the OPENSSL_VERSION_TEXT counterpart but I don't see the equivalent as a number, in OpenSSL there is OPENSSL_VERSION_NUMBER which is used for doing #if (OPENSSL_VERSION_NUMBER >= 0x1010107f) in the code for example, this is really important for maintenance if we want to support multiple versions of aws-lc. - AWSLC_API_VERSION maybe this would be enough instead of the VERSION_NUMBER. We could activate the HAVE_SSL_* defines using OPENSSL_VERSION_NUMBER and this. > > To Alex's concern on API compatibility: yes AWS-LC is aiming to provide a > > more stable API. We already run integration tests with 6 other projects [2] > > including HAProxy. This will help ensure API compatibility going forward. > > What is your specific concern with ABI compatibility? Are you looking to > > take > > the haproxy executable built with OpenSSL libcrypto/libssl and drop in > > AWS-LC > > without recompiling haproxy? Or do that between AWS-LC libcrypto/libssl > > versions? > > I personally have no interest in cross-libs ABI compatibility because > that does not make much sense, particularly when considering that Openssl > does not support QUIC so by definition there will be many symbol-level > differences. Regarding aws-lc's libs over time, yes for the users it > would be desirable that within a stable branch it's possible to update > the library or the application in any order without having to rebuild > the application. We all know that it's something that only becomes > possible once the lib stabilizes enough to avoid invasive backports in > stable branches. I don't know what the current status is for aws-lc's > stable branches at the moment. > Agreed, cross-libs ABI is not useful, but the ABI should remain stable between minor releases so the library package could be updated without rebuilding every software that depends on it. Regards, -- William Lallemand 0001-BUILD-ssl-Build-with-new-cryptographic-library-AWS-LC.patch Description: 0001-BUILD-ssl-Build-with-new-cryptographic-library-AWS-LC.patch 0002-Add-build-cache-for-AWS-LC.patch Descr
HAProxy Working Mechanism and its implications on Lua scripts
Hi, team! Since I am pretty new to this service, I have a question about this powerful load balancer tool HAProxy's working mechanism at the lower level of process and threads. I have gone through the documentation, but it seems that the explanation of the working mechanism is pretty high-level and focus on what it does and how it could be configured to achieve different goals of routing client requests to proper backends. I am more interested in how HAProxy manages processes and threads to achieve the highly efficient distribution of incoming client connections and requests to workers (not sure what specifically a worker means for HAProxy scheduler) and how workers process the request independently (or with shared resources). I would be really appreciate if someone explains this mechanism or gives a lead to look up. (either in codebase or doc with details) I am also trying to add a lua script to the HAProxy configuration file to be executed for each incoming request. This Lua script will make network requests using the header data from the incoming client request being handled to an external service, (e.g. a backend or a data store like Redis etc) to get a response. Then HAProxy redirects the routes according to this response. Since I am trying to add this lua script and it will be executed for almost each incoming request, I am trying to evaluate the performance effect of adding this script. I read docs of adding lua script in HAProxy, and figured out network calls are non-blocking to the main thread of HAProxy, but I still want to understand how it works at low level and what effects it has so that I know what I am doing here. Thank you very much! Looking forward to your reply! Best regards,Ryan
Re: WebTransport support/roadmap
Looks like that's Websocket for udp/QUIC just because the Websocket Protocol does not work with QUIC, imho. From a cursory read of https://github.com/w3c/webtransport/blob/main/explainer.md, it seems to have slightly different goals from traditional Websocket though. Notably to sacrifice message ordering to get rid of head-of-line blocking. Cite from https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2/ ``` By relying only on generic HTTP semantics, this protocol might allow deployment using any HTTP version. However, this document only defines negotiation for HTTP/2 [HTTP2] as the current most common TCP-based fallback to HTTP/3. ``` They do have a separate HTTP/3 specific draft here: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3 When I look back how a nightmare the Websocket in the different version was to implement it will this variant for QUIC not be much easier, from my point of view. Now as for complexity, I can only agree that I hope it will be simpler for everyone, implementers as well as users... since easiness of use really was not a strong point of WS... Tristan
Re: WebTransport support/roadmap
Hi. On 2023-08-16 (Mi.) 17:29, Artur wrote: Hello ! I wonder if there is a roadmap to support WebTransport protocol in haproxy. There are some explanations/references (if needed) from socket.io dev team that started to support it : https://socket.io/get-started/webtransport Looks like that's Websocket for udp/QUIC just because the Websocket Protocol does not work with QUIC, imho. Cite from https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2/ ``` By relying only on generic HTTP semantics, this protocol might allow deployment using any HTTP version. However, this document only defines negotiation for HTTP/2 [HTTP2] as the current most common TCP-based fallback to HTTP/3. ``` Please can you open a Feature request on https://github.com/haproxy/haproxy/issues so that anybody, maybe you :-), can pick it and implement it. When I look back how a nightmare the Websocket in the different version was to implement it will this variant for QUIC not be much easier, from my point of view. Jm2c -- Best regards, Artur Regards Alex
RE: [PATCH] MEDIUM: sample: Implement sample fetch for arbitrary PROXY protocol v2 TLV values
Hi Willy,
Thanks for the clarifications. I've implemented your requested changes and
split my changes in 6 consecutive patches.
I was not able to use a check function for authority and unique_id without
modifying sample.c or allowing an argument.
As far as I can tell, the check function is only executed for sample fetches
that have not specified 0 for the arg function.
I think it's okay this way since, semantically, those function do not handle
arguments, so doing the argument setup internally makes sense IMO.
If there is way to adjust this without any hacks, I will of course apply it.
For now, I have appended them to this message to not cause to much spam on the
list while also keeping the previous, related discussion.
If I should send them individually, please tell me and I will do so.
Restructuring, especially in regard to pooling lead to quite a bit of changes,
but the overall logic still applies and should hopefully be relatively straight
forward.
Actually, the code even got simpler in many places! :)
BTW, I also added some TLV type constants in the 6th patch, feel free to merge
it or ignore it.
I think it helps with readability and is not really risky.
If there should be a nit that you quickly want to change, feel free to. I am
not upset about it at all.
Best,
Alexander
-Original Message-
From: Willy Tarreau
Sent: Sunday, August 13, 2023 10:01 AM
To: Stephan, Alexander
Cc: haproxy@formilux.org
Subject: Re: [PATCH] MEDIUM: sample: Implement sample fetch for arbitrary PROXY
protocol v2 TLV values
[You don't often get email from w...@1wt.eu. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
Hi Alexander,
On Fri, Aug 11, 2023 at 02:08:37PM +, Stephan, Alexander wrote:
> Hi Willy,
>
> Thanks for the nice, detailed feedback.
> Overall, I agree with all of your listed points, so no need for further
> discussions. ?
> I will hopefully send the separated patches at the beginning of next week.
OK! No rush anyway, such changes having a low impact can be merged late in the
cycle if needed, so take your time.
> Just a comment and two small questions to make sure I got things correct:
>
> > As such I'd like them to be renamed to remove this confusion.
> > Maybe just call them HA_PP2_* ?
>
> Yes, such a prefix will clean it up quite nicely IMO. Will add that to
> the first patch of the series.
Thanks.
> > [...]
> > It may even encourage us to create
> > smaller pools if ever deemed really useful (e.g. a 4- or 8- byte
> > load balancing hash key for end-to-end consistency would only take a
> > total of 32 or 40, malloc included).
>
> Just to make sure: Right now, we don't want to optimize further for
> small TLVs other than removing the second pool for the values and
> using the new struct with the VLA to reduce the overhead.
> For normal use, a pool with 160 B could be used now to accommodate
> for the new conn_tlv_list struct and 128 B TLVs (e.g., UNIQUE_ID)?
> For the authority type, it would then be a 255 + 32 B sized pool?
> Maybe that could be used for the value range 128 <= x <= 255, and
> then, for > 255, malloc?
Yes I think that will do the job (more like 128 < x < 256 BTW). I think you'd
rather just focus on the type size (like you did) and not on the type itself,
so that pools will automatically fit (i.e. have
128+sizeof(conn_tlv_list) and 256+sizeof() and the rest is for malloc().
> Other, smaller pools are future work?
Yes, as I'm not sure they're really that much used, and it will be easy to
create smaller pools if we figure they're needed.
> >struct conn_tlv_list {
> > struct list list;
> >unsigned short len; // 65535 should be more than enough!
> >unsigned char type;
> >char contents[0];
> > };
>
> I am also a bit confused about the second struct variant of this. IMO
> this is the optimal struct layout in regards to size, that I would like to
> use.
> What is the other struct for, where `len` and `type` are switched?
Ah, at first I didn't know what you were talking about, I remember having added
the type while writing the message, it's just that I poorly pasted it the
second time :-) It's better to keep it as above, where types are better
aligned and leave no hole. Hmmm BTW the struct will be padded, so you should
use offsetof(conn_tlv_list, contents) rather than
sizeof(conn_tlv_list) for the size calculations. Or you can mark the struct
with __attribute__((packed)), it will do the job as well. It's up to you.
> Thanks again for your efforts, it's really interesting for me to work
> on HAProxy.
You're welcome, do not hesitate to send any question you may have.
Cheers,
Willy
0001-CLEANUP-MINOR-connection-Improve-consistency-of-PPv2.patch
Description: 0001-CLEANUP-MINOR-connection-Improve-consistency-of-PPv2.patch
0002-MEDIUM-connection-Generic-list-based-allocation-and-.patch
Description: 0002-MEDIUM-connection-Generic-list-based-allocation-and-.patch
0003-M
WebTransport support/roadmap
Hello ! I wonder if there is a roadmap to support WebTransport protocol in haproxy. There are some explanations/references (if needed) from socket.io dev team that started to support it : https://socket.io/get-started/webtransport -- Best regards, Artur
