> You are forgetting that there may be more than one health applications > running over HDP at the same time, if one of them creates a data > channel, that data data channel will be exist at MCAP level even if > the initiator abort the connection. If other application wants to > create a new data channel with the same configuration, it may be want > reconnect that data channel avoiding to create another data channel. > It is a best practise wich is recomended in MCAP and best explained in > the Health Device Profile white paper document to reduce the amount of > data interchanged between medical devices (in IEEE/11073-20601 > terminology: "agents" and "managers"). Remember that channels may be > shared between applications. I'm still not convinced :) I can't see the point of sharing a HealthChannel that is not healthy (pardon the joke). Maybe I'm being too pragmatic, but I expect that most real HDP devices will be like that Nonin oximeter: incapable of reconnecting MDLs and incapable of accepting connections. Sharing a channel in that situation will make spend much more, not less, energy, because applications will Acquire() and trigger a reconnection over a channel that actually does not exist and wouldn't be accepted even if it existed. Anyway, MDL aborts are expected to be rare, so the actual problem won't be seen often in practice. I think we have another, more important problem: naming the channel after MDLID. For example, the channel that comes from oximeter has always the same path here: /org/bluez/19750/hci0/dev_00_1C_05_00_28_85/chan1. It is incapable of reconnections but always recreates the MDL with the same MDL ID = 1. Now, let's suppose a MDL is created, destroyed and re-created, but for some reason the application the application takes too long to act upon the signal. You have three signals: ChannelConnected chan1 ChannelDeleted chan1 ChannelConnected chan1 (a second channel with the same MDL ID) Application will Acquire() on first signal, thinking it is getting the FD for the first instance of chan1, but it will actually get the FD for the second "version" of chan1. Then it will process the ChannelDeleted signal, closing a perfectly good channel. And then it sees the third signal, and tries the Acquire() the fd it has just closed. If the other side tries to reconnect immediately but does not support MCAP reconnections, this could go on forever. A possible solution is to use a monotonic number for the channel path suffix, without relation to MDL ID.-- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
