dmarszk
commented
5 years ago Extra commentary from a discussion with @SamCooper (SC)
DM: Is it a valid behaviour for MAL implementation to track every interaction with a certain (configurable and optional) timeout window for a response from the provider, and if the interaction times out, could it generate a timeout error and push it to the application? This would apply to all interaction patterns having any kind of a response or ACK message (SUBMIT, REQUEST, PROGRESS and PUBSUB_REGISTER/DEREGISTER and PUBSUB_PUBLISHER_REGISTER/DEREGISTER). SC: Absolutely, the MAL only defines the messages and the order they must be passed in. It does not define timeouts because what they are (and whether you have them) is completely dependent on your situation.
DM: Should such error be pushed to the application as a locally produced MAL message? What MAL Error type should it use? How would such message be distinguished from a message coming from the remote provider? SC: A timeout is still a normal MAL error, as in it is a MAL think rather than a Java API thing. The MAL already defines several possible error codes for you to use if you look at Table 5-1 in the MAL blue book. DELIVERY_TIMEOUT seems to be the obvious choice in this case but others may be more appropriate.
DM: If a SPP reassembly timeout occurs on the transport - should it be pushed upwards to a MALTransmitErrorListener (I think it is dedicated to the TX errors)? Is this in any way implemented in our current stack implementation? Point 4.6.5 e) of MAL SPP Binding only mentions discarding the sequence SC: With reassembly timeout there are two errors to consider, one in the sending side and one in the receiving side. Once you think about it like that you should start to see how it should be handled, and that how it should be handled is situation dependent. I.e. you may want to handle reassembly failure in reception of a SUBMIT ACK message differently to failure of the initial SUBMIT message.
Also see related MAL error code proposed in: SamCooper/MAL_SPEC_RIDS/issues/20
CesarCoelho
Not all underlying transports (e.g. SPP) can always ensure message delivery. Furthermore, the remote endpoint might be non-existent, or not responding. Currently, MAL implementation tracks all interactions and waits for the response infinitely. The interactions should be able to time out locally inside the MAL implementation, raising a MAL Error to the application layer in a configured and predictable manner.
@SamCooper if you agree, we will go ahead and implement it.