mirror of https://github.com/OPCFoundation/UA-.NETStandard.git synced 2026-10-17 05:11:13 +08:00

Files

T

Copilot d525bc3f28 Bound reconnect cleanup and organize samples by domain (#4276 )

# Description

This PR fixes bounded ManagedSession reconnect cleanup and reorganizes
the sample applications into domain-focused folders.

## Reconnect cleanup

- Bounds reconnect integration cleanup with independent 30-second close
and dispose limits.
- Sends `CloseSession` through the awaited transport request path during
`Session.DisposeAsync`.
- Preserves explicit `Session.CloseAsync` behavior that waits for or
cancels outstanding publish requests.
- Covers the disposal request path with a regression test.

## Sample organization

- `samples/OpenUsd`: `GeneratorServer`, `SiteCompositionServer`
- `samples/Redundancy`: `RedundantClient`, `RedundantServer`,
`RedundantPubSub`
- `samples/Isa95`: `MinimalIsa95Server`
- `samples/MinimalApi`: `MinimalBoilerServer`, `MinimalCalcServer`,
`MinimalClient`
- `samples/DI`: `PumpDeviceIntegrationServer`
- `samples/Lds`: `ConsoleLdsServer`
- `samples/Reference`: `ConsoleReferenceClient`,
`ConsoleReferenceServer`
- `samples/PubSub`: `ConsoleReferencePubSubClient`

`UA.slnx` now exposes the same requested domain groups. Project
references, tests, runtime sample probes, CI workflows, Dockerfiles,
Compose files, helper scripts, and documentation were updated to the new
paths. `samples/Robotics/MinimalRobotServer` remains under `Robotics`.

## Validation

- `dotnet build UA.slnx`
- 3 Redundancy short-haul sample tests
- 70 DI sample tests
- 914 OpenUSD tests
- 1 WotCon model-materialization test
- 137 AOT tests
- `docker compose config` for all 6 moved Redundancy Compose files

## Related Issues

- Fixes #4273

## Checklist

- [ ] 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.
- [x] 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.
- [x] I have verified that my changes do not introduce new build or
analyzer warnings.
- [x] I built the complete `UA.slnx` solution locally.
- [ ] I ran all tests locally against at least .NET Framework and .NET
10.
- [ ] I fixed all failing and flaky tests in the CI pipelines and all
CodeQL warnings.
- [x] I have addressed all PR feedback received.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: marcschier <11168470+marcschier@users.noreply.github.com>
Co-authored-by: Marc Schier <mschier@microsoft.com>
Co-authored-by: Marc Schier <marcschier@users.noreply.github.com>
Copilot-Session: a2c2838f-74ae-4997-a1d4-50574d9e0636

2026-08-21 04:35:47 +00:00

2.8 KiB

Raw Blame History

OPC Foundation UA .NET Standard Reference Server

Introduction

The console reference server can be configured using several console parameters. Some of these parameters are explained in more detail below.

To see all available parameters call console reference server with the parameter -h.

Reverse Connect

The OPC UA reverse connect feature allows an OPC UA server to initiate the connection to a client, rather than the traditional model where clients connect to servers. This is particularly useful in scenarios where the server is behind a firewall or NAT, making it difficult for clients to directly connect to it.

How to use Reverse Connect

To enable reverse connect mode, specify the client endpoint URL using the --rc or --reverseconnect parameter:

dotnet ConsoleReferenceServer.dll --rc=opc.tcp://localhost:65300

dotnet ConsoleReferenceServer.dll --reverseconnect=opc.tcp://localhost:65300

Example: Server and Client with Reverse Connect

Start the client with reverse connect listener on port 65300:

dotnet ConsoleReferenceClient.dll --rc=opc.tcp://localhost:65300 opc.tcp://localhost:62541/Quickstarts/ReferenceServer

In a separate terminal, start the server with reverse connect to the client:
```
dotnet ConsoleReferenceServer.dll --rc=opc.tcp://localhost:65300 -a
```

The server will establish a reverse connection to the client endpoint, and the client will use this connection to communicate with the server.

Additional Options

-a or --autoaccept: Auto accept untrusted certificates (for testing only)
-c or --console: Log to console
-l or --log: Log app output
-t or --timeout: Timeout in seconds to exit application

For the complete list of options, use --help.

X509 user identity certificates

The reference server validates X509 user identity tokens against its trusted-user certificate store (TrustedUserCertificates, by default %LocalApplicationData%/OPC Foundation/pki/trustedUser). An untrusted user certificate is rejected with BadIdentityTokenRejected — the --autoaccept option only auto-accepts the application/channel certificate, never user identity certificates.

To let a trusted client (for example the OPC Foundation Compliance Test Tool) authenticate with an X509 user token, its user certificate must be present in that store. To make provisioning easy, the server writes every rejected X509 user certificate to a dedicated review store, pki/rejectedUser (a sibling of pki/trustedUser). After one failing activation you can move the legitimate user certificate from pki/rejectedUser/certs into pki/trustedUser/certs (and any issuing CA into pki/issuerUser/certs) and reconnect. Deliberately-untrusted certificates simply stay out of the trusted store and continue to be rejected.

2.8 KiB Raw Blame History