2023年10月25日(水) 12:42 Martin Thomson <[email protected]>: > On Wed, Oct 25, 2023, at 13:52, Kazuho Oku wrote: > > FWIW my complaint against the original approach was that it needs yet > > another mechanism to limit concurrency (as without one there would be > > concern of state exhaustion) and that I do not like it. > > I don't think that this has concurrency issues. You receive a frame, you > send a frame.
The problem is that clients can send an arbitrary number of requests (as identified by request IDs) and that servers have to track the responses that they send for each response. That said, Igor's idea is attractive. With some allowance for endpoints > throttling updates on frequent changes, With Igor's approach, this protection already exists thanks to the active_connection_id_limit Transport Parameter. An endpoint can send updates only as much as the number of paths that it can open at a time. > that would reduce the number of frames we need and improve reliability. > Endpoint advertises support in transport parameter; peer sends frame when > it adds a path. > -- Kazuho Oku
