mirror of
https://github.com/OPCFoundation/UA-.NETStandard.git
synced 2026-10-25 11:50:03 +08:00
MarcandCopilot
6d57355eea
A review against the OPC UA Data Channels errata found five defects. Four are implementation faults; two of them also exposed gaps in the draft, which are proposed separately in the drafts repository. Validate transportChannelId where the result is visible (Part 6 7.4) QuicServerDataChannelTransport.BindClientStreamAsync discarded the task carrying every 7.4 check, so a Client could name the control stream, a stream it did not initiate, or one already bound, and the Server answered Good and echoed the value. The checks were right; nothing consumed them. Validation and stream reservation now run inline where a refusal becomes the Service result. Only the wait for the stream to materialize stays deferred, because a peer-initiated QUIC stream is observable only once the peer writes to it and a Client writes only after it has the response - awaiting it would deadlock the exchange rather than order it. Stop one unread channel stalling the SecureChannel (Part 6 5.8) The delivery queue was bounded in frames but sized from a byte credit, and it blocked when full. Small frames therefore filled it long before credit ran out, and the block landed on the reader that also carries MSG, OPN and CLO, so a slow consumer on one channel stalled every Session, Subscription and Publish on the connection - the opposite of "stalls that stream and nothing else". The queue is now bounded by encoded frame bytes, as 7.4 bounds the unknown-ChannelId buffer and for the same reason, and a peer that exceeds the bound is reset rather than waited on. This also removes a sync-over-async violation. Open the channel when the response is dispatched, not before (Part 4 5.1) OnResponseSent ran before the response object was encoded, so MarkOpen could wake the scheduler and put a frame for a ChannelId on the wire ahead of the response naming it. SecureChannelContext gains an optional ResponseDispatched callback that both listeners invoke after handing the response to the transport; it is inert when unset. The scheduler additionally refuses to serve a channel still Opening, which is what the 5.13 state table already said. Carry inline data channels instead of discarding them (Part 6 5.16) A Server advertised opc.tcp, accepted OpenDataChannel, and then dropped every frame through a transport whose send path did nothing - the silent drop 5.16 forbids. InlineServerDataChannelTransport resolves the UASC channel behind the request and enables the engine on it, so channels ride the connection the Client already holds. A SecureChannel that can carry no frames is now refused with Bad_DataChannelTransportUnsupported. Give Uncertain_DataDiscarded its own identifier It shared identifier 1111 with Bad_DataChannelFrameTypeUnsupported. The two differ only in severity bits, so the collision produced valid but wrong constants instead of a build error; it is now 1113. The generator fails on a duplicate identifier and a test asserts the emitted constants are unique. Every regression test added here goes through the production entry point rather than the component, because that is precisely what the existing component-level tests missed in all four wiring defects. Opc.Ua.Core.DataChannels.Tests 284 pass on net10.0 and 212 on net48; Opc.Ua.Server.Tests 4072 pass; Opc.Ua.Sessions.Tests 776 pass with test discovery unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5d026b47-265d-4c97-8715-26e207dfa03c