The specification should address a standard manner of supporting a client that will write multiple values in an efficient manner. Multiple manners of providing this support have been discussed in emails. Parts of these emails are included in this mantis. The key requirement is that in some cases a client may be the source of a value in the server. The value is only updated by the client. The updated rate will be variable and in some cases may be at a fairly high rate. A single client may be the source of multiple nodes. Multiple Clients may be the source of their own unique lists of nodes. Although a simple write operation could accomplish the updates, a write operation is not optimized for this type of writing. The optimization applies to server side code, messages size on the write and client side operations.

Issues raised in discussions:

• error handling – how would errors for individual writes be handled? How about entire block write errors?
• Current write include nodeId, attribute ID and array index – this overhead should be eliminated, much like it is for a subscription – where only an Item id is passed. a) Write is not as optimized as DataChange. DataChange has 4 Byte overhead per delivered DataValue. Write (even with registered NodeIDs) has 12 Byte overhead per delivered DataValue.
• The Server will need to be able to support subscriptions to the items that are being written by the Client, where a different Client would get values for the particular item as if it was being sourced by some built in data source in the Server.
• Other issues that need to be reviewed and discussed include redundancy, disconnect/reconnect issues etc. This service should behave much like a subscription in that it should have a timeout that is different than the session timeout. It should support the same robust communication items provided by subscription.

This new feature could be implemented via new services or via new methods on the Server object – Methods may be easier to add (no stack updates), but would have more overhead, could also have support related issues, in that the functionality will not be provided as part of a stack (ensuring all implementations are the same). Services would be more efficient, but are a major change. The functionality required in either case may include items such as
• CreateWriteSubscription (tells the server that this client will be sourcing values)
• AddItemsToWrite (the items that are being written, maybe locking them from other clients)
• SubscribeWrite (the actual write operation)
• RegisterNodeExtended (allow more then just nodeId, but attributeId and array index)

From emails:

Matthias - a) Defining a method is not perfect because a method call has more overhead than a service and support for an optional method will not be better than support for a new service. Defining a new service should cover more use cases than just the one you are describing. An optimized write can also serve as simplified write for embedded systems. We can define a Write that takes a list of NodeIds and a list of DataValues and that returns a list of StatusCodes. The NodeId can be either a cyclic write handle NodeId or a fully qualified NodeId / registered NodeId. For the cyclic write handle we need an extended RegisterNode that takes not only a NodeId but also AttributeId, IndexRange and Encoding. In the case where the NodeId is not cyclic write handle, AttributeId is set to Value and IndexRanve and Encoding to null on the server side to execute the write. The same can be used to define a simplified Read.

Karl - what you describe looks very much like DX where target items had been connected to values in a client. In DX, however, the target server always had to be the actor and therefore had to be a client. If we remove this requirement, we have to reverse the subscription concept from data change into SubscribedWrite. Everything else stays the same; the server would disable write access for any other source (client), the server can negotiate the rate at which writes come in and assure it has the resources and is able to handle the load.