On Tue, Feb 25, 2020 at 12:26:41PM +0100, Tim Düsterhus wrote:
> > 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.
Indeed for TCP it can make some sense to have something like this.
> > 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));
You can even do :
struct stream *stream = si_strm(si);
Because the chain looks like this :
+------------------------+
conn--mux--cs--| si[0] stream si[1] |--cs--mux--conn
+------------------------+
Front Back
When you do si_opposite(si[1]) it gives you si[0] and conversely.
Both are part of the same struct stream. Thus si_strm() returns
the same stream for any of them.
> As mentioned above: TCP proxying instead of HTTP. Unless my
> understanding of 1 connection = 1 stream for TCP is incorrect.
No, it is correct.
> > 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.
Yes it's always better if this can be avoided.
> 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?
I don't know yet. I'm just a bit concerned about the risk of having
something in TCP that disappears in HTTP if you do it for TCP only.
Someone using this connection ID for logging (that's often the purpose)
would only have it with TCP and would have to proceed differently for
HTTP. So I'm still wondering if it wouldn't be better to rely on
"proxy-v2-options" and decide what to send, and when the unique-id is
specified there, then it's taken from the stream, regardless of the
stream mode (tcp/http). Even if I consider that it doesn't make sense
to have this ID sent both on the connection and in a header, if there
is a use case to having such an ID on a connection, we must still be
sure that it doesn't become impossible to send it when in HTTP.
Also maybe having a way to retrieve a received ID on a listener as a
sample fetch so as to be able to build a unique-id header from it
could be useful. Some users want to pass the same ID along a whole
chain, and with this it would become possible at the TCP level, which
is quite nice.
Cheers,
Willy
