Willy, thank you for the reply.
Am 25.02.20 um 11:57 schrieb Willy Tarreau: >> I'm currently attempting to extend Proxy Protocol v2 by a new TLV to >> send a unique ID for TCP connections, similar to the unique-id-header >> for HTTP. >> >> I'm currently struggling to get the `struct stream` within >> `make_proxy_line_v2`. I could find out that I can get the `struct >> session` via `remote->owner`, but from there I have no idea how to get a >> `struct stream`. By printing the allocations it appears that a stream >> should already exist by the time the proxy line is sent. > > You will not get back to a stream based on a connection because there > may be many streams per connection. A connection will lead you to a > mux (H1,H2,FCGI) and from there depending on the mux's protocol and > internals you'll have 0 to many streams above. The specific use case I'm exploring is unique IDs for TCP proxying. I believe for TCP there should be a 1:1 mapping between connections and streams, no? Anything HTTP can and should just use the header. > However in many cases you could know the stream that requested the > outgoing connection. That's what is used when you see that "remote" > thing. In conn_si_send_proxy(), there's a test to see if the the > first connection's conn_stream's owner is a stream_interface, and > if so it uses si_opposite() to find the other side. From this > stream interface you can get the requesting stream using si_strm(). So I would do: struct stream *stream = si_strm(si_opposite(si)); similar to that: struct conn_stream *remote_cs = objt_cs(si_opposite(si)->end); ? I'll try that, thanks. >> So questions: >> 1. Would it generally work to send a unique ID within the proxy line or >> will that cause issues? > > I'm not seeing any particular issues, however this would require a > strict definition of how the unique-id is built. I'm assuming you > want to use the same unique-id as the one built per-stream, but the > problem is that you'll get many streams over a connection, and that > at most one of them will have the same ID as the connection (and > possibly even none of them), and the other ones will remain unrelated. > In this context one can wonder what's the benefit of building an ID at > the stream level to use it at the connection level. As mentioned above: TCP proxying instead of HTTP. Unless my understanding of 1 connection = 1 stream for TCP is incorrect. > Maybe you just need a per-connection unique ID. But in this case we > might need a way similar to the existing one to define the format. > Or maybe you should just resort to a UUID that is sent only when > some option is used ? Yes, that would be my escape hatch if I could not get a stream. In fact the current version of my code has the unique ID on the connection. However I liked the idea of not adding another configuration option. Asking differently: If I wanted to upstream my proposal (with the explicit focus on unique IDs for TCP), how would you like to see it work? >> 2. How can I grab the `struct stream` from the `struct connection >> remote` or more general: How can I get the correct `struct stream` from >> within `make_proxy_line_v2`? > > From within make_proxy_line_v2() you're too low for this but in > conn_si_send_proxy() it's OK. Just be careful about what I mentioned > above regarding unicity vs streams. Best regards Tim Düsterhus
