Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Upload/write a config file from OPC Client to the server over FileType Object
February 5, 2021
11:38, EET
Avatar
Nan
Member
Members
Forum Posts: 10
Member Since:
December 14, 2020
sp_UserOfflineSmall Offline

Hi Team,

I have created a FileType Object node in UAModeler, generated xml and generated corresponding java code in server (which is using prosys java SDK).
I have created a class at server side which extends FileTypeNode. Client used is UAExpert.

My requirement is:
-The client(UAExpert) either uploads a configuration(xml) file to the server or writes the file maybe using open(),write() and close() method of FileTypeNode.
-The server would then validate or perform some action on the file.

The write method needs a FileHandler which I read is returned by the open() method.I try to call open method from UAExpert with mode as 2(write mode
).The call goes to FileTypeNode’s open()which throws Status exception “file not writable” because this.isCurrentWritable() is false.

1)I tried setting writable and UserWritable variable to true from UAModeler in order to call open method. But the issue still remains.
The variables(writable/UserWritable) value is blank in UAExpert and DataType is null whereas it is set to true with access level 15 from UAModeleler
2)If written successfuly, can the file be stored/accessed from the Session?Where does the file store/how to access it.
Or some other way to access the file and perform any validation/action on the file in server code.
3)Is there any File size limitation while using FileType Object

Kindly help.

Thanks

February 5, 2021
12:42, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 620
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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.).

February 5, 2021
15:10, EET
Avatar
Nan
Member
Members
Forum Posts: 10
Member Since:
December 14, 2020
sp_UserOfflineSmall Offline

Hi,

Thanks for the explanation.

“You must call setFile(File file) on the FileTypeNode instance, otherwise it wont work (by design). All operations are done to that File”
1)Could you please explain if it’s possible to call setFile(File file) method from UAExpert client? Because there is no setFile(File file) method in FileType object node.
2)If I understand it correctly, do I need to call setFile(File file) method from the server itself on the FileTypeNode instance and then call open,write and close from the UAExpert client.///How to call setFile(File file) method.
3)Should there be a physical copy of the file present on the server.

February 5, 2021
15:31, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 620
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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.

February 8, 2021
12:02, EET
Avatar
Nan
Member
Members
Forum Posts: 10
Member Since:
December 14, 2020
sp_UserOfflineSmall Offline

Thanks, setFile(file) is working for me now. Once called, I can see file size from UAExpert in “size” variable of FileType node. I am able to read/write as well.

Is there a limit on file size that I can write using FileTypeNode .Currently I am able to write 1086Kb of file. In future if File size increases, do I need to write in chunks? If so, what’s the maximum chunk size I can write at once.

Thanks

February 9, 2021
10:42, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 620
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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).

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
7 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 109

pramanj: 86

ibrahim: 71

kapsl: 57

gjevremovic: 49

TimK: 41

fred: 41

Fransua33: 39

Xavier: 34

Thomas Reuther: 33

Member Stats:

Guest Posters: 0

Members: 1221

Moderators: 15

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1089

Posts: 4591

Newest Members:

aravindj, Deniz.Turan, DenizT, igonzalez, lavonwinters963, felicapurdy9, shoshanastopford, UlrichFM, majaba, Yash_Joshi_Pratiti

Moderators: Jouni Aro: 865, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 620, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Teppo Uimonen: 21, Markus Johansson: 30, Matti Siponen: 92, Lusetti: 0

Administrators: admin: 1