matter.js

86b97420 - Messagetiming (#1165)

Messagetiming (#1165) * Introduces SessionContext ... to have a typed view on methods common for all types used as Context (MatterDevice/MatterController) * Re-Announce device when resubmission starts ... as defined by specs. This is not that much about securing this communication because the client might not get any data but the client can so better rediscover the device when itself gets not response * Adjust test mocks * Adjust resubmission handling * Adjust concept from "max wait time" to "expected peer processing time" which is just a part of the complete wait time to be provided from app level. * The default expected processing time from chip is currently 2s, so use this if nothing else is provided * maximumPeerResponseTime now calculates the maximum peer resend cycle time * After all resubmissions were done we now wait for a full resubmission cycle from the peer * Adjust read handling regarding timeouts When reading/expecting responses we now also consider the expected peer processing time and a timout based on resubmissions (if MRP is used) or hard values for other cases like TCP or BLE. Because of the fact that we go down from fixed 60s in the past to mostly lower values I added another 5s buffer time for network latencies and other cases. * Use new sen/receive parameters in InteractionMessenger Even that it looks like that the "expectedProcessingTime" is applied twice this is only partially true. Our send waits until an ack is received. If the ack is sent directly then we just wait the additional time on reading next message. If the ack is send piggybacked on response the "nextmessage" call resolvs immediately because response is already there. Only special cases will wait twice, but they should be fine and go more into the old 60s from before, but limited. * Adjust timings for CASE/PASE Asd discovered in chip code basically all PASE/CASE messages use a long expected processing time of 30s because of crypto actions on low-budget devices. So we also adjust the timing here. Only call which is using a lower expected processing time are the PbkdfParam* calls, so we default to 30s like chip and just use shorter time for these calls * changelog