[Documentation] Partial Invoke Responses are very unclear in Specification about connectedhomeip HOT 5 OPEN

With the information written in "10.7.10.2. MoreChunkedMessages" one can assume that the above logic should happen as soon as the "last message" 8the one with moreChunkedMessages=false" was arrived. Is this the right assumption and interpretation?

Yes that is correct. It is something provided by Interaction Model layer to let the Application layer know that the server has not sent a response to that invoke interaction at the time that the server has indicated that the Invoke interaction is completed.

from connectedhomeip.

@tehampson to get emails about this thread with how my email filters are set up

from connectedhomeip.

Thank you for verifying my assumptions. I think it could help to redce the confusion a bit whe the spec contains an additional sentence about it.

One side question for "multiple invokes": Whats a good "max number" if there is not natural limit because of RAM or such? Ok there is a natural maximum for UDP based messages, like 57 invokes as max ... but with TCP it could be more, right? In fact it is a uint16, but I think it makes no sense to allow 65k invokes ;-)

from connectedhomeip.

Thank you for verifying my assumptions. I think it could help to redce the confusion a bit whe the spec contains an additional sentence about it.

Do you have a recommendation on what to change/add? If you don't that is fine, it's just that I helped fix some part of the spec here so sometime I may be to close and may think that certain aspects are already.

One side question for "multiple invokes": Whats a good "max number" if there is not natural limit because of RAM or such? Ok there is a natural maximum for UDP based messages, like 57 invokes as max ... but with TCP it could be more, right? In fact it is a uint16, but I think it makes no sense to allow 65k invokes ;-)

yeah with UDP I found the max to tap out at around 57 command in the packet. But as you said TCP support is coming along.

Without knowing what exactly you are trying to optimize for it is hard to provide a recommendation. Also depends on server or client?

Server - whatever the constraint server device want to support up to the max of uint16 (IIRC). This is essentially an optional feature if the device doesn't want to support it at all they can just say MAX_PATHS_PER_INVOKE and nothing should ever send a batch command to it.

Client - depends on the constrains of the client device. If it is a fairly sizable device why not support whatever a theoretical max server code support 65k? Who know what the future hold and if there is a very large bridge device that may be on an industrial scale.
That said a client that supports sending out batch commands needs to be dynamic to a degree. If your API accepts batch of n, but the server only supports receiving 1, the client code already need to handle splitting that work up to n individual commands, so you could use that same logic to break it down to whatever you think that clients max should be. So the API could accept 65k, but your implementation breaks it up to chunks of whatever you think a reasonable.

from connectedhomeip.

Will think about textual ideas and provide here tomorrow.

For the Max-Invoke-Paths: I completely agree with you, because in fact I miss a bit the real world use cases for it. In fact it is about the "default max invoke paths" for matter.js as a framework (that can be overridden by the developer if needed) ... so my feeling is to go with something like 10 untell someine has good reasonsn for more - or stay at 1 :-)

And sure the controller/Client need to check how to send stuff and depending what the server allows it need to do multiple messages or send one.

Thank you for your feedback"

from connectedhomeip.