Skip to content

Home

Jump to bottom
locka99 edited this page Nov 3, 2017 · 6 revisions

Welcome to OPC UA for Rust

This wiki will contain things related to the project that aren't necessarily suitable for the general README.md file.

Wishlist / Aspiration

The readme says what the project is but doesn't say where the project wants to go, or areas of improvement. So let's list some here.

General

  1. Examine Rust best practice to improve the APIs. For example, code should make use of traits like Into<> on constructors where it makes sense. One benefit of doing this is that it cuts down the amount of constructors laying around the place. codes, or is it better to say Good and BadUnexpected.
  2. Make the code robust and resilient against attack. e.g. stop malformed data or timeouts from breaking functionality.
  3. Try and identify why the Rust plugin for IntelliJ has such terrible performance with the codebase. Is it confused by potentially recursive "use" statements or what?
  4. Sweep the code looking for inefficient use of clone, move etc.
  5. Consolidate OPC UA's weird naming syntax with Rust's. e.g. should we use GOOD and BAD_UNEXPECTED for status or Good, Bad_Unexpected, or BadUnexpected?
  6. Consider if enums in OPC UA Schemas can be autogenerated rather than written by hand.
  7. Consider if tools that read OPC UA schemas can be written in Rust, possibly at runtime instead of NodeJS, or if that's too much bother.
  8. Consider if some mini convenience crates can be used to reduce the amount of code crud, e.g. replacing nested if statements with a match!() command or similar.

Client

The client lags behind the server in terms of functionality and testing. It can connect to a server anonymously over unsecured channel and ask for some values.

It should be able to:

  1. Log on with a username and password during activate session
  2. Cryptographic support.
    1. Create a pki key structure including storing server certs in rejected
    2. Validate server cert for trust
    3. Exchange nonce and signatures
  3. Subscription and item monitoring. The ability to create a subscription to zero or more items and to monitor those items.
  4. Sample client should be able to exercise the client functionality
  5. Conform to an OPC UA profile for embedded clients
  6. It would be nice to implement a sample client that does something useful, e.g. implements an http server so a consumer can read values over http request or even over a websocket. Another interesting idea might be an MQTT / OPC UA bridge, all written with Rust - i.e. values change in server, client pushes events over MQTT.

Server

The server is the main focus of development.

  1. X509 user token identity support
  2. Activate session resumption. If a client disconnects from a server and tries to resume, the server should hold the dead session in storage and allow it to be reconnected. Perhaps the server holds the last 5 sessions in cold storage
  3. Fix performance / lost messages in subscription monitoring. Clients connected to the existing implementation complain of duplicate acknowledgements and other glitches which suggest it is dropping packets.
  4. Test all modes of item monitoring, e.g. publish / report modes
  5. Timeouts on dead sessions
  6. Robust limit enforcements to prevent objects exceeding published limits

Crypto

Crypto is supplied by OpenSSL through some Rust bindings. OpenSSL is a very robust and comprehensive library but it is written in C which goes against the idea of a Rust implementation of OPC UA. In addition OpenSSL complicates building the product. OpenSSL was also the cause of the One(!) memory exception I've experienced during development.

Replacing OpenSSL requires Rust implementations of the following, preferably from a single, mature crypto crate

  1. AES encryption / decryption
  2. RSA encryption / decryption
  3. Public / private key creation, read and write to .der support
  4. SHA-1 and SHA-256 hashing
  5. X509 certificate creation, read and write to .x509 support
  6. PKCS1 and OAEP padding
  7. Asymmetric signing/verification with RSA + SHA-1 or SHA-256

Comms

The communication layer is how stuff is sent back and forth between client and server. Technically the client and server will have different layers for their purpose, but they'll be treated as one for this list.

  1. Investigate using tokio. The current networking layer is over sockets with a polling loop. Tokio is likely to be much more efficient, especially for servers looking to serve multiple clients for less resources.
  2. Implement multiple chunks. The client / server may like messages to be broken up into chunks to send over the wire. The current comms layer only supports one chunk although the chunking functionality is already written.

Testing

  1. Add an integration test suite to test client and server apis together
  2. Extend tests to more service calls.
  3. Benchmark and long term testing
  4. Review OPC UA test cases online and try to manually or auto test them.
Clone this wiki locally