[BUG] Multiple CASE establishment

[DanijelBojcic]

Reproduction steps

We are using Matter for offline communication between our hardware and app. The hardware is running as a matter bridge - I'll call it Controller.

We have achieved to skip the commissioning flow by preloading RCAC,NOC,IPK,CATS,etc. - This way the app and the Controller only need to initiate a CASE session.
When the app renders a card on the UI it subscribes to its Controller.

The problem occurs when the app renders multiple cards that are on multiple Controllers. Matter performs multiple OperationalSessionSetup::LookupPeerAddress, which results in only the first one to succeed, every other session will timeout. I have created an interval on the Java side, which recalls the subscribe on every errored node every 15 secs. In every cycle only one DNSSD lookup will succeed. One-by-one it will subscribe to every Controller, but thats not acceptable

I tried to workaround the issue by establishing a CASE with an IP address, because in most cases the app already knows the Controllers IP. In this method the sigma1 and the sigma2 is being sent and received, but the sigma3 is only sent by the app, but it times out. ( Sometimes it worked though like a charm )

I don't know if its a bug or it is supposed to be working like this, but it would be nice if the core would implement a queue or something like that.

Bug prevalence

every time

GitHub hash of the SDK that was being used

4088a77

Platform

android

Platform Version(s)

1.0.0.2

Anything else?

No response

[bzbarsky-apple]

which results in only the first one to succeed

That sounds like an Android-specific bug. Certainly on iOS multiple parallel resolves work just fine.

[DanijelBojcic]

So it's definitely not a dnssd limitation?

[bzbarsky-apple]

Not a general one, no. Specific implementations may have problems, of course.

[DanijelBojcic]

Just leaving a note here, maybe it will help someone:
Our custom function establishCaseWithIP- which works around the DNSSD bug - does not work with 5 or more parallel calls because the fifth call fails silently. After a quick debugging, we found that matter limits parallel CASE's to 4 with CHIP_CONFIG_UNAUTHENTICATED_CONNECTION_POOL_SIZE 4.

@bzbarsky-apple
Shouldn't it be handled at core level with a queue?

Or maybe OperationalSessionSetup::EstablishConnection shouldn't fail silently when it hits CHIP_ERROR_NO_MEMORY. I've just realized that this is handled with callbacks.

[bzbarsky-apple]

@DanijelBojcic On a constrained device, you can't queue up things: if there is no memory, then there is no memory.

CHIP_CONFIG_UNAUTHENTICATED_CONNECTION_POOL_SIZE is only used as a template argument to UnauthenticatedSessionTable, as kMaxSessionCount. The kMaxSessionCount argument is only used here:

ObjectPool<UnauthenticatedSession, kMaxSessionCount> mEntries;

ObjectPool can operate in two modes. If CHIP_SYSTEM_CONFIG_POOL_USE_HEAP is set true, it will ignore the size argument and just heap-allocate things. If it's false, it will have an actual fixed-size pool.

I would have expected Android to set CHIP_SYSTEM_CONFIG_POOL_USE_HEAP to true by default, but src/platform/android/SystemPlatformConfig.h does not seem to do that. If it did, there would be no size constraints on this pool, which is presumably the desired pool behavior on Android in general.

[yunhanw-google]

#28451 may fix your issue @DanijelBojcic

[yunhanw-google]

@DanijelBojcic I assume this issue is resolved, if this is still outstanding, please kindly reopen it, thanks