Both of you are assuming a request/response paradigm. That is pretty much the only model we have been using but it isn't the only model and it is a straightjacket.
On Fri, Sep 30, 2022 at 7:44 PM Christian Huitema <[email protected]> wrote: > > On 9/30/2022 4:30 PM, Randy Armstrong (OPC) wrote: > > * Sure, we could design a presentation layer on top of QUIC. I > think it is better to design a transport/presentation layer for the problem > space and then see how we might make use of QUIC. > > > > Not quite sure why you make a big deal about this. OPC UA supports the > kinds of operations you described but the complex operations are broken > into multiple request-response pairs for transport. All OPC UA needs is a > full duplex channel that allows responses to be returned in any order. I > would imagine that any other protocol built on QUIC would do the same. > That's exactly the way DNS over QUIC is designed. Full duplex channel > (QUIC connection) allowing for series of transactions. Each transaction > request (from the client) is mapped to a new duplex stream stream; > response come back on the reverse part of that stream; responses to > transactions arrive in any order. > > The important question is: does QUIC have any inherent limitations that > would make it difficult to implement complex operations over top of QUIC? > > No. > > You have to pay attention to the management of connections, how to > resume connections after they break, etc. But that's pretty standard > when designing a distributed application. > > -- Christian Huitema > > >
