Hi,

In my personal opinion, I would personally avoid trying to use FileType in general. I would look all other options first.

But if you must.. (and well, yes there are some valid scenarios where that is the only practical choice, but in general all interoperability typically goes out of the window)

The FileTypeNode just represents a concept of a file, it by itself wont do anything. You must call setFile(File file) on the FileTypeNode instance, otherwise it wont work (by design). All operations are done to that File. Also please note that in most cases you should also make some user access controls, e.g. via IoManagerListener on the IoManager of the NodeManager where your instance of the FileType Object is. In addition, if you would automate that in any way (setting the File) please remember to do sanitization of file names etc, otherwise you basically open a path for any client to e.g. delete and/or read all files of the system. In general this is the reason why it wont by default do anything, as great care should be taken when used.

No UserXXX Attribute should be set in UaModeler, that is a design error of the NodeSet2 models in practice. In general a single value doesn’t really work since it should be user-specific. We also made the error when we originally designed the UaNode API (like, it does make sense in the client side, but not on the server side). Thus therefore those must instead be reactively returned in the SDK in IoManagerListener (or well, the Attribute values never guarantee that you could do the operation, so in theory you can also just fail it it CallableListener made to a MethodManager of the NodeManager).

P.S.
Like in general, it will work, but you should have some out-of-baud way to know that the file was written correctly (e.g. some checksums). In addition, there are a number of problems that appears once you are outside the realm of OPC UA (which Files are, in my opinion). Please ensure that no other application is writing or reading the file while the SDK would. While we do basically the calls within Java that will open a file in write mode, in reality it is OS and other app dependant are there any _real_ locks in place and even then sometimes other apps can chose to … just ignore them.

P.S.2.
Limits otherwise are pretty much are what they are for the File object you give. Do not expect reading/writing performance to be great though. It was pretty abysmall the last time we tested, and due to the overhead of UA it can be a lot (since you normally you do that a chunk at a time thus latency is multiplied for each chunk etc.).

1. No. I meant java-method, not OPC UA-method. Otherwise it would be a security risk since any server that would allow making new instances from the client side could get access to the local disk, which would not be good. Thus it must be coded to the server application itself that it can work with files and thus required precautionary steps are done. In general that is why I would personally avoid using files altogether where possible.

2. Yes. You would e.g. search the node after you have loaded the model and cast it to FileTypeNode and then after that you should be able to call that method.

3. A java File object maps typically to a “physical file”, so yes. Though technically SDK doesn’t like exactly care what it does internally, but as far as I’m aware a java.io.File is always something that maps to a physical file (but you could make e.g. a RAM disk). If we are at the future not in Java 6 land for that part in the SDK, we most likely would be using Path instead, which would allow e.g. in-memory impls.

I do not have a definitive answer to that at the moment. Depends on a number of factors.
– FileType Size Property’s DataType is UInt64, so 18,446,744,073,709,551,615 Bytes is theoretical maximum.
– Your Physical disk size and/or OS limits are probably lower
– Interally we use RandomAccessFile, whose position setting is a long, thus 9,223,372,036,854,775,807 bytes is max via that way
– Client and Server agree on a size limit on a Message, which most likely is lower than all above.
– Individual Method Calls are bound to the Session
– Your network has some limit on bandwidth

I believe our server side defaults are 4194240 bytes on a whole OPC UA Message, but that is with all the service call overheads of headers etc. not sure what amount is useable by the raw ByteString that you would use, and not 100% sure would it still be limited by some other factor. But if you get a Bad_EncodingLimitsExceeded when you would try to write, that would indicate too big of a size (the client side should throw this directly to you). If the client side is not our SDK, the limit can be less, it is basically the minimum of client and server limits.

If (per the post title) you are using this just for a configuration file upload, then it probably wont matter that much if you just decide on some relatively low chunk size. Since I would assume you not to repeatedly being updating the configuration, i.e. that it wont matter does it take like e.g. 1, 2, or 5 minutes to complete.

P.S.
Personally I would say that it would be more “OPC UA-like” to do e.g. a Structure for the configuration, and make that update-able from a node/method. But if the configuration could be too large for that (goes over the binary limits), then I guess using files is the only way at some point (or splitting the configuration to multiple nodes). If you use files, there is no self-mapping-metadata from the server to determine the configuration file format, unless you e.g. use XML and make a schema available e.g. from a node (though, even then, it would be outside the realm of OPC UA).