Large data transfers in RPC calls

Summary

I agree that the message size should not matter to the user and should be, if required, fragmented in the lower layers.

However, this is not how the rpcsvc framework/service is designed; the messages must be kept relatively small, under 8 MiB. You could probably work around it in the templated RPC framework; it would probably be easier and faster to re-write the rpcsvc daemon. Also, the RPC calls are not designed as a streaming service, so that the whole message must be buffered at some point... but the memory is limited in the CTP7.

From @lpetre.

Neither the rpcsvc service nor the template RPC frameworks were designed for large data transfers. They require the whole dataset to be available before sending it.

An option to implement this feature would be to open a socket, allowing the two ends of a call to communicate asynchronously while the call is running. This could be achieved by constructing a special data type whose serialization and deserialization hooks would handle the socket. It would be passed as function arguments. It would not be trivial to implement and use.

The size of the configuration is driven by VFAT data. Each channel is 2 bytes, plus 18x4 bytes for control registers. Therefore an AMC configuration is O(100kB).

From @lmoureau.

What is the expected correct behavior?

Decide whether the feature is needed and desired. Design and implement a solution it if the answer to both these questions is "yes".