When I use the IDL editor on Eclipse and generate the RPC client, I found that the variable array has been initialized as an array with zero length, which is unexpected.
2. Does the arrays with variable upper-bounds and maximum supported as below, which can be mapped to Java?
Example of arrays with variable upper-bounds and maximum
I think this should work.
At least there are customer using NAT62 using dynamic tables in natural and give or return a variable number of occurences.
You need to start an natural rpc server with the right NAT61 protocol. In unix this is a parameter of the make file.
for tables with 1 dimension I can guarantee it works because I have done it.
On the level of natural you there is an instruction to increase and decrease the number of occurences of a table;
Concerning the question of size, this depends on limits you need to fix on the level of the broker (there is a parameter for maximum length of message) and on the level of MAX_BUFF on the level of the RPC server.
After reading your reply, I have a few follow-up questions.
In EntireX Communicator documentation of v.7.3.2 - Administration of EntireX RPC server - Setting Server Parameters for the RPC server, I cannot figure out the parameter <MAX_BUFF>. May you give me a pointer on this?
If <MAX_BUFF> is the fundamental constraint imposed on the size of the reply from EntireX broker, then
a. What is its default setting? and how large can parameter <MAX_BUFF> be set?
b. Will setting the compression level help to increase the maximum bounds of variable array?
c. What happen when the size of response is larger than <MAX_BUFF> can hold? It seems that using variable array in the request/response invocation does not give a reliable RPC handling. In such case, would we have a reliable method to handle these responses?
Go back to my question on my 1st post, are there any Best Practice on retrieving the list of structural data with variable-length? It would nice if there is a document describing the general practice on designing the interface particular for EntireX RPC server.
Thanks for your reply. But I still have doubt on how using conversational RPC communication can help resolving the issue of buffer overflow in handling variable array.
Issue 1
What make conversational RPC communication different from the non-conversational one is just the “connection-oriented” feature. It just make your life easier on handling the life cycle of transaction involving multiple remote calls to Entire-X RPC server.
In this sense, I don’t understand how using conversational RPC will help.
Issue 2
To use converational RPC, it will to a very large extent increase the resource overhead to the RPC server, and reduce its thoughput, not to say that it will also increase the development/maintenance overhead. I have the understanding that the conversational RPC communication should be used in a caution way, and only it is very necessary. Please correct me if I am wrong.
It is still a myth to me on handling the variable-length of list of structural data reliablely in the RPC call.
You’re right its Issue 1 and did not help It is too lang ago i used my last conversational RPC so i asked a team-mate and he also said that conversational is a cycle of calls. :oops:
There is a Broker setting of MAX-MESSAGE-LENGTH also (as Jose mentions). It defaults to 31647 and can be up to 2GB (depending on transport protocol). A single message size (MAXBUFF for Natural) cannot exceed MAX-MESSAGE-LENGTH.
It is too lang ago i used my last conversational RPC so i asked a team-mate and he also said that conversational is a cycle of calls. :oops: