Hello all, Again I'm writing in the hope of soliciting opinions, this time pondering support for UDS in the PROXY protocol.
If we release a version of Varnish as "now supporting UDS", it might seem logical to support UDS for PROXY as well. But that doesn't necessarily follow -- if Varnish supports UDS for listen and backend addresses, it may still reject PROXY headers that denote a UDS. As of now, I'm thinking that would be the right way to go. But I'm a bit concerned that there may be no good way to support PROXY with UDS in the foreseeable future, for reasons I'll try to explain. For one thing, the use case is evidently marginal. UDS in a PROXY header would mean that someone is running a proxy that listens at a UDS and forwards to Varnish, and wants to tell Varnish via PROXY about its UDS listen address. That setup is evidently rare enough that no one seems to have complained about Varnish rejecting such a PROXY header. Also, PROXYv1 (the human-readable format) doesn't support UDS, The address family is either TCPv4 or TCPv6, anything else is UNKNOWN. So the only the possible scenario is receiving AF_UNIX via PROXYv2. Conceivably, we could support that. The difficulty I see is: * We convert the addresses from the PROXY header to VSAs, which become the session attributes for the client and server addresses in session workspace. * We wanted to avoid adding the storage for sockaddr_un (128 bytes each, with about 100 bytes for the path) to session workspace. * I can't think of any good place besides session workspace to put the UDS addresses sent via PROXY. When PROXYv2 sends AF_UNIX, there are two addresses, 108 bytes each, so the protocol specifies 216 bytes. Where should the storage go? So far in the fork, I have VSAs with a pointer to sockaddr_un, and someone is the "owner" of the storage that it points to, responsible for freeing it. So VSAs don't become any larger, and don't take up more session workspace (on my machine, a VSA is 40 bytes). For listen addresses, the owner is the management process, who has the pointers to the sockaddr_un's in the pool of listen_socks, which is handed off to the child via heritage.socks. The pool is valid for the lifetime for the mgt process, so the sockaddr_un storage just dies when mgt exits (this was already the case for the pool of listen_socks before the introduction of UDS). For backend addresses, the owner is struct backend, which now has pointers to a UDS VSA and a sockaddr_un. These are freed in VBE_Delete. In any other UDS VSA duplicated from one of those, such as the session attributes or the TCP pool for a backend, the pointer to sockaddr_un in the VSA is copied from the owner -- it "points back" to the space managed by the owner. Those components don't attempt to free the pointer. I'm pretty happy about how this has turned out, because I think it keeps the sockaddr_un storage needs down to the minimum necessary, and manages the storage the right way. (Still interested in feedback about that.) But as presently conceived, the addresses sent via PROXY are "owned" by a session, and become invalid when the session closes. Theoretically, PROXY could send a different address every time, but in practice the address sent would be the same almost every time, at least on one listen address. So we could have an external table of sockaddr_un's created from PROXY headers, and VSAs in session workspace would point to entries in the table. That would mean sessions receiving a UDS via PROXY would have to search the table, strcmp against their paths, and insert new sockaddr_un's as necessary. Something would have to take care of garbage collecting the table occasionally. At any rate, my recommendation is: * Don't support UDS via PROXYv2 for the time being, even if we support UDS for listen and backend addresses. * Put the question of storage for sockaddr_un's derived from PROXY on the list of ponderables for the future. As usual, comments are welcome. Thanks, Geoff -- ** * * UPLEX - Nils Goroll Systemoptimierung Scheffelstraße 32 22301 Hamburg Tel +49 40 2880 5731 Mob +49 176 636 90917 Fax +49 40 42949753 http://uplex.de
signature.asc
Description: OpenPGP digital signature
_______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
