Files
UA-.NETStandard/docs/AsyncServerSupport.md
T
5899354441 Clarify documentation, migration guidance, and SDK selection (#4823)
# Description

Remove stock phrasing and correct misleading or inconsistent technical
documentation. The initial two passes covered 367 Markdown files,
followed by an interactive review of 169 editorial flags. The U5
interpretation originally deferred in that review has since received the
upstream Mantis answer recorded by #4843; remaining server/spec
follow-ups stay explicit in the CTT log.

- Correct package responsibilities, migration steps, API names,
ownership, protocol descriptions and links. Keep bundled migration
guides synchronized. Preserve historical conclusions as historical
records with separate re-check notes.
- Provide at least two rendered TOC levels throughout `docs/`. Convert
appropriate architecture figures to Mermaid without changing code
examples, transcripts or historical quotations.
- Address the October 19 feedback with concrete setup/migration
instructions, corrected certificate paths and PubSub names, shorter
repeated caveats, consistent XML comments, and a full review of the
Concepts guide. Retain #4839's API corrections.
- Integrate #4841's runtime/performance guidance and review
incoming/recent prose. Preserve dated measurements rather than claiming
new benchmark runs; clarify allocation ratios, startup-only processor
settings, JIT warm-up and the benchmark commit's scope. Missing raw
measurement artifacts and repeat ranges remain tracked by #4842.
- Merge master through `e8c5d800a` in `32c6394b7`. Resolve the CTT log
conflict using the updated Mantis states and OPC answers, retaining
historical framing and re-checks for C28/C32/C43.
- Address the latest naming/index feedback in `adb5bf693`: rename the
guides to `docs/WotCon.md` and `docs/WotNodeSetConversion.md`; move the
provider and DataType-declaration contracts into the conversion guide
and remove `docs/WoT.md`. Rename `samples/DI` to `samples/Di` and
`samples/Isa95` to `samples/ISA95`. Add content-index READMEs to Di,
FluentApi, ISA95, Lds and PubSub; update solution entries, project
references, Docker/CI paths, test fixture paths and documentation links
with exact casing.

**WoT guide scope.** This branch retains the detailed conversion guide
that #4758 had replaced with an anchor stub. Conversion limits, verified
document sets, preservation rules and provider ownership now live
together in `WotNodeSetConversion.md`; binding/runtime guidance remains
in `WotBindings.md` and `WotCon.md`. The design-rationale/test-ledger
prose was shortened, the oversized argument-table cell moved into its
section, and existing anchors preserved.

**SDK policy is a separate, explicit user-directed change.**
`global.json` sets a stable minimum of `10.0.400`, `rollForward:
latestMajor`, and `allowPrerelease: false`. Newer major SDKs are
permitted; CI's explicit SDK pins are unchanged. README, GettingStarted,
DeveloperGuide and Recycling instructions reflect the possible analyzer
differences. The image-contract regression fix accepts compatible stable
SDK images instead of requiring exact equality with the floor.

The latest four rename/index threads are resolved after publication.
Three older threads remain open: universal obsolete-removal timing,
unconditional nonce-strength wording, and a blanket Vision NativeAOT
claim. Existing implementation/evidence constraints are explained in
their inline replies. The two-level TOCs remain as requested.

## Validation

- `git diff --check` and staged diff checks: passed. The untouched
upstream AutoID NodeSet retains its provenance bytes, including two
existing license-header trailing spaces.
- `.\.azurepipelines\validate-migration-plugin.ps1`: passed; 15 bundled
migration documents and manifests synchronized.
- Documentation/path validation: **101** documents retain two rendered
TOC levels (**2,228** entries), with idempotent formatting. **52** new
relative links and their anchors passed exact-case checks. No tracked
references to the old guide/sample paths remain. Both relocated
provider-contract sections are preserved in the destination.
- `dotnet sln UA.slnx list`: passed; shows the renamed Di/ISA95 projects
and the existing FluentApi/Lds/PubSub projects. Updated solution and
pump ProjectReference paths also passed exact-case existence checks.
- Latest focused commands, run from the repository root:

```powershell
# Passed: 61 channel send-order and reconnect tests.
dotnet test tests\Opc.Ua.Core.Tests\Opc.Ua.Core.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~UaSCBinaryChannelSendOrderTests|FullyQualifiedName~TcpReconnectKeyAgreementTests' --verbosity minimal

# Passed: 5 pump datasheet tests; builds the renamed pump sample.
dotnet test tests\Opc.Ua.Di.Tests\Opc.Ua.Di.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~PumpDatasheetConformanceTests' --verbosity minimal

# Passed: 4 repository NodeSet path/round-trip tests, including the moved pump models.
dotnet test tests\Opc.Ua.Types.Tests\Opc.Ua.Types.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~RepositorySourceSurvivesSerializedLinkedPartitionsAsync' --verbosity minimal

# Passed: build, zero warnings/errors.
dotnet build samples\ISA95\MinimalIsa95Server\MinimalIsa95Server.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal

# Passed: dependent sample-test project build, zero warnings/errors.
dotnet build tests\Opc.Ua.WotCon.Samples.Tests\Opc.Ua.WotCon.Samples.Tests.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal
```

Earlier focused integration checks passed 2,620 tests across AutoID,
event queues/scheduling, source generation, MCP/package profiles and
WoT. Both reviewed Mermaid diagrams rendered locally without network
access. These checks are not a full solution run.

The full solution has **not** been rerun for this review. Earlier
`dotnet test UA.slnx -p:CustomTestTarget=net10.0 --verbosity quiet` did
not pass: three AOT projects rejected VSTest and 20 Vision tests failed
during graphics initialization with `OutOfMemoryException`. Remaining
long-running tests were stopped at the user's request. A focused Vision
rerun passed 558 tests and reproduced those 20 failures. The earlier
`dotnet test UA.slnx -p:CustomTestTarget=net48 --verbosity quiet` was
blocked by the former SDK pin and was not retried after the policy
change. The user approved proceeding with those limitations documented;
current remote CI is not claimed green.

## Related Issues

- Follow-up #4842 tracks the requested 2.0.2+ benchmark/tuning and
diagnostic-tool documentation refresh. #4841 supplies documentation and
earlier results, not all newly requested measurements.
- #4758 explains the conversion guide's earlier consolidation; the
current provider contracts are now consolidated into
`WotNodeSetConversion.md`.
- #4839 supplies the reviewed API corrections; #4843 supplies the
updated CTT issue record.
- The original prose cleanup and SDK policy were user-requested without
a source issue. No new runtime architecture is introduced by these
documentation edits.

## Checklist

_Put an `x` in the boxes that apply. You can complete these step by step
after opening the PR._

- [ ] I have signed the
[CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf)
and read the
[CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md)
doc.
- [ ] I have added tests that prove my fix is effective or that my
feature works and increased code coverage.
- [x] I have added all necessary documentation.
- [ ] I have verified that my changes do not introduce (new) build or
analyzer warnings.
- [ ] I ran **all** tests locally using the **UA.slnx** solution against
at least .net **framework** and .net **10**, and all passed.
- [ ] I fixed **all** failing and flaky tests in the CI pipelines and
**all** CodeQL warnings.
- [ ] I have addressed **all** PR feedback received.

---------

Co-authored-by: Roman Ettlinger <romanett98@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-21 10:10:55 +02:00

14 KiB

Support of the TAP (Task Asynchronous Pattern) for server operations

The OPC UA .NET Standard stack has long supported asynchronous server operations through the APM (Asynchronous Programming Model). APM uses IAsyncResult and the Begin/End pattern. .NET Framework 1.0 introduced this pattern, which remains supported in .NET 8.0.

The stack also supports TAP for server operations. TAP uses task-based APIs with async/await and is the recommended pattern for asynchronous server code.

Server applications can implement node managers with TAP to await I/O without blocking a request worker.

The server library provides these TAP features:

  • Task-based RequestQueue and TransportListenerCallback
  • Generated code and MasterNodeManager support Task-based operations.
  • The IAsyncNodeManager interface supports fully asynchronous node managers.
  • AsyncNodeManagerAdapter and SyncNodeManagerAdapter let synchronous and asynchronous node managers run side by side.

Contents

Upgrading an existing server

  • Update INodeManager.CreateMonitoredItems to support the new MonitoredItemIdFactory.
  • AsyncCustomNodeManager is the recommended base class for fully asynchronous node managers; see AsyncCustomNodeManager.
  • Keep using CustomNodeManager2 and implement the asynchronous interfaces your server needs:
    • IAsyncNodeManager for full async support
    • ICallAsyncNodeManager for async method calls
    • IReadAsyncNodeManager for async reading
    • IWriteAsyncNodeManager for async writing
    • IHistoryReadAsyncNodeManager for async history read
    • IHistoryUpdateAsyncNodeManager for async history update
    • IConditionRefreshAsyncNodeManager for async condition refresh
    • ITranslateBrowsePathAsyncNodeManager for async translate browse path
    • IBrowseAsyncNodeManager for async browsing
    • ISetMonitoringModeAsyncNodeManager for async monitoring mode changes
    • ITransferMonitoredItemsAsyncNodeManager for async monitored item transfer
    • IDeleteMonitoredItemsAsyncNodeManager for async monitored item deletion
    • IModifyMonitoredItemsAsyncNodeManager for async monitored item modification
    • ICreateMonitoredItemsAsyncNodeManager for async monitored item creation

MasterNodeManager detects which asynchronous interfaces a node manager implements. It uses an asynchronous implementation when available and otherwise falls back to the synchronous implementation.

  • The server supports fully asynchronous node managers that implement IAsyncNodeManager. Register one with StandardServer.RegisterNodeManager(IAsyncNodeManagerFactory). IAsyncNodeManager.SyncNodeManager is required for compatibility; pass the node manager to SyncNodeManagerAdapter to provide it.

Async method calls

CustomNodeManager2 supports asynchronous method callbacks. Implement IAsyncNodeManager on your node manager to enable them. Generated method state classes expose asynchronous callbacks such as UpdateCertificateMethodState.OnCallAsync; the server uses these callbacks when the node manager implements the interface. For a generic method handler, use MethodState.OnCallMethod2Async.

AsyncCustomNodeManager

AsyncCustomNodeManager is the recommended base class for building fully async, TAP-native node managers. Unlike the older CustomNodeManager2, it implements IAsyncNodeManager directly rather than INodeManager3. This has two practical consequences:

  • All virtual methods are async ValueTask-returning from the start, so there is no boilerplate wrapping of synchronous code inside Task.Run or similar helpers.
  • The SyncNodeManager property (required by IAsyncNodeManager) is satisfied automatically: the constructor calls this.ToSyncNodeManager() and stores the resulting INodeManager3 adapter. Callers that still require an INodeManager3 reference (e.g. legacy subscription code) use that adapter; the node manager itself never needs to implement the synchronous interface.

Registering an AsyncCustomNodeManager

Use the IAsyncNodeManagerFactory overload of StandardServer.RegisterNodeManager:

server.RegisterNodeManager(context =>
    new MyAsyncNodeManager(server, configuration));

Async browse iteration

Every hook a custom node manager overrides is awaitable, including browse operations. AsyncCustomNodeManager.BrowseAsync and TranslateBrowsePathAsync iterate an INodeBrowser with NextAsync(CancellationToken) instead of Next(). A browser can therefore fetch data from an underlying system asynchronously. For example, it can retrieve references from another server without occupying a request worker with a blocking call. The default NextAsync wraps Next(), so the browsers provided by the stack and existing custom browsers continue to work. See NodeManagers.md for the browser contract.

Locking strategy vs CustomNodeManager2

The synchronous CustomNodeManager2 service paths use coarse-grained manager synchronization. AsyncCustomNodeManager instead coordinates writes and monitored-item management with awaitable semaphores while leaving node-state synchronization inside NodeState.

The following describes the implementation, not locks that application callers should acquire. Use the manager's service, lifecycle, and fluent APIs so operation admission, cancellation, and disposal remain coordinated.

1. Global write semaphore — m_writeSemaphore

The manager serializes its Write service operations through an awaitable semaphore. Read operations do not acquire it. The semaphore does not turn external updates or several attribute accesses into a transaction; use the node APIs for state access.

2. Monitored-item semaphore — m_monitoredItemSemaphore

A second SemaphoreSlim(1, 1) serializes monitored-item management operations. It keeps subscription state consistent without blocking reads or writes. The semaphore protects:

  • create, modify, and delete operations
  • monitoring-mode changes
  • event subscriptions and condition refresh
  • monitored-item transfers

3. Per-node locking for read and attribute access

Reads do not acquire a manager-wide lock. NodeState synchronizes attribute and collection access internally; the async manager awaits ReadAttributeAsync so that asynchronous value handlers can complete without blocking a thread.

Do not use lock (node) or lock (handle.Node). Those monitors do not coordinate with the node's private locks and cannot protect its state. Use the node's attribute, child, and reference APIs instead. Individually synchronized operations do not form an atomic multi-attribute transaction.

See the threading contract for nodes and browsers for supported operations, snapshot boundaries, and browser ownership.

Concern CustomNodeManager2 AsyncCustomNodeManager
Address-space reads Manager synchronization Internally synchronized node APIs
Write service operations Manager synchronization Awaitable write serialization
Monitored-item management Manager synchronization Awaitable monitored-item serialization
Awaiting asynchronous handlers Use the asynchronous path Supported by asynchronous operations
Implemented interface INodeManager3 IAsyncNodeManager

Monitored-item manager selection

The constructor accepts an optional useSamplingGroups flag:

// Default: change-triggered (MonitoredNodeMonitoredItemManager)
public MyNodeManager(IServerInternal server, ApplicationConfiguration config)
    : base(server, config) { }

// Opt-in: timer-based sampling (SamplingGroupMonitoredItemManager)
public MyNodeManager(IServerInternal server, ApplicationConfiguration config)
    : base(server, config, useSamplingGroups: true) { }
  • MonitoredNodeMonitoredItemManager (default): node value changes are propagated to subscribers immediately by awaiting NodeState.ClearChangeMasksAsync after every successful write (see Fully asynchronous change notifications). No background threads are created per subscription.
  • SamplingGroupMonitoredItemManager: a background timer thread samples the current node value at the negotiated SamplingInterval. Write changes are not pushed immediately; instead the next scheduled sample detects and delivers them. Choose this mode when the data source produces values independently of OPC UA write requests (e.g. hardware polling).

Fully asynchronous change notifications

AsyncCustomNodeManager sends value changes and events to monitored items through an asynchronous push path. This path does not block a thread when a node uses an asynchronous value-read handler or when the per-node notification channel applies back-pressure.

The per-node channel admits two pending notifications behind the active consumer. Each notification retains its enqueue-time attribute values, including large structures and subscriber-specific copies. Producers asynchronously wait when that bound is reached; accepted data changes and events are preserved in order rather than discarded. Await the asynchronous reporting APIs so a slow consumer cannot accumulate thousands of retained snapshots.

Subscriber-specific access checks use values captured for that subscriber at enqueue time. A subscriber joining behind an already queued change does not inherit the reporter's denied value when no value was captured for the new subscriber. It receives its initial value and subsequent changes instead. The dispatcher does not reread the node for that notification, because a reread could return a later value. Subscribers denied access receive the corresponding error. Captured subscriber-specific values also retain their session and identity attribution. Attaching or transferring an item before dispatch cannot make it inherit an older owner's captured value or unauthenticated access-denied result.

NodeState exposes asynchronous counterparts of its change-notification API alongside the existing synchronous members:

Synchronous Asynchronous
ClearChangeMasks(context, includeChildren) ClearChangeMasksAsync(context, includeChildren, ct)
OnStateChanged / StateChanged OnStateChangedAsync / StateChangedAsync
ReportEvent(context, e) ReportEventAsync(context, e, ct)
OnReportEvent OnReportEventAsync

These additions do not break existing synchronous callers or sinks. MonitoredNodeMonitoredItemManager wires the asynchronous sinks. After a successful write, AsyncCustomNodeManager.WriteAsync flushes changes by awaiting handle.Node.ClearChangeMasksAsync(...).

The asynchronous sink reads each monitored attribute through NodeState.ReadAttributeAsync. When registered, an asynchronous OnReadValueAsync or OnSimpleReadValueAsync handler supplies the value. The sink then enqueues that snapshot through the bounded per-node channel and awaits completion. It reads the value before enqueueing the change, so each notification captures the node value at the time of the change. Awaiting both operations keeps the producing thread from blocking.

The synchronous ClearChangeMasks and ReportEvent methods also drive the asynchronous sinks. They complete inline when the node is synchronously readable and the channel has capacity. They block the calling thread only while an asynchronous read is in flight or the channel is full. Synchronous node managers continue to work without changes, but may block in those two cases.

Each monitored item's queue controls overflow and discard behavior, including FIFO/LIFO DiscardOldest and the Overflow status bit. The shared per-node channel does not drop notifications. As a result, the configured queue policy applies to the full stream of changes.

Creating a custom node manager

Derive from AsyncCustomNodeManager and override only the virtual methods you need:

public class MyNodeManager : AsyncCustomNodeManager
{
    public MyNodeManager(IServerInternal server, ApplicationConfiguration config)
        : base(server, config, "http://my.org/UA/Data/")
    {
    }

    public override async ValueTask CreateAddressSpaceAsync(
        IDictionary<NodeId, IList<IReference>> externalReferences,
        CancellationToken cancellationToken = default)
    {
        await base.CreateAddressSpaceAsync(externalReferences, cancellationToken)
                  .ConfigureAwait(false);

        // build your nodes here
        var myVar = new BaseDataVariableState(null);
        myVar.NodeId  = new NodeId("MyVar", NamespaceIndex);
        myVar.Value   = 42;
        await AddNodeAsync(SystemContext, default, myVar, cancellationToken)
              .ConfigureAwait(false);
    }
}