Taking a look in the code, I saw that hdp_mcap_mdl_aborted_cb() emits a ChannelConnected signal.
I understand that after an abort, the MDL still exists, and can be reconnected, so I understand the intention of informing the application that a channel has been "created". But I'm not sure that it is opportune.
The first thing the application will do is trying to Acquire() the channel's file descriptor (that does not exist) and that triggers a reconnection attempt, from acceptor to initiator. While the most sensible thing (in my view) is waiting for the initiator to reconnect -- if it aborted, it must have a good reason, and it will probably reject the immediate call back.
What do you think?
Hello Elvis,
2010/10/24 Elvis Pf?tzenreuter <[email protected]>:
>
>> sure?
>> Then you should think what happen with the First reliable data channel
>> in case that you are running multiples IEEE specializations over the
>> same HDP instance (that is pretty common in IEEE level). Remember that
>> the First Relible data channel is used for IEEE association and
>> confirmed event traffic. If you dont allow use that channel by other
>> application it won't associate with the other device at IEEE layer.
>> Please, think that with current HDP implementation you can develop
>> IEEE agent specializations too, not only managers.
>
> Ok, I think I see your point now. Thanks for the patience :)
>
Don't worry. comments are welcome, in any case, If you have more
doubts, please don't hesitate in contact with me, we can talk more
about that and others issues in IRC, the only problem may be the time
difference ;)
Regards
> sure?
> Then you should think what happen with the First reliable data channel
> in case that you are running multiples IEEE specializations over the
> same HDP instance (that is pretty common in IEEE level). Remember that
> the First Relible data channel is used for IEEE association and
> confirmed event traffic. If you dont allow use that channel by other
> application it won't associate with the other device at IEEE layer.
> Please, think that with current HDP implementation you can develop
> IEEE agent specializations too, not only managers.
Ok, I think I see your point now. Thanks for the patience :)
> Sorry, you are right about that, reconnections are not mantadory in
> all cases for sources. May be we should check this flags before
> keeping the state and emitting the signal.
This could be useful even in this case of MDL abort X ChannelConnected signal. If the flags say that device is incapable of reconnections, definetively no point in emitting the signal.
But I am not sure if you will have the SDP record at hand to do this check, at that moment; certainly not worth forcing a SDP query just to round these particular corner cases.
2010/10/24 Elvis Pf?tzenreuter <[email protected]>:
> Hello,
>
>> In that case, the problem is in the remote side, because the Bluetooth
>> SIG certification requires the devices to support reconnections, so
>> the problem is not in our side but in the remote side that isn't
>> compliant with the standard. I think we don't ?have to change our
>> implementation regarding buggy devices that don't follow the
>> specification correctly.
>
> I think an HDP device is NOT required to support reconnections. In HDP spec item 5.2.11 ? there is that bitmap in SDP record that says whether device supports reconnections and CSP.
Sorry, you are right about that, reconnections are not mantadory in
all cases for sources. May be we should check this flags before
keeping the state and emitting the signal.
>
>> More over, the situation that you mention. When receiving a
>> ChannelDeletion, the application shouldn't close the data channel,
>> because the in the normal situation, the DBus object for the data
>> channel will be removed, so no closing of the channel will be
>> performed, the only thing that should happen is that the application
>> will "forget" about this channel. When the second ChannelConnected is
>> received, the application will typically perform an acquire that, in
>> this case, will be very simple because the channel will be already
>> connected and the fd will be transmitted.
>
> So the application must follow a very specific behaviour when handling a ChannelDeleted signal, and worse yet, it must do it to fix a problem that we could fix simply by changing the way channel paths are named.
>
The only thing that the application should do when receiving a
ChannelDeleted signal is to forget about this channel because the
Channel object does not exists any more and no more calls to the
channel API could be done. Nevertheless if you close the fd get from
the Acquire petition, nothing will happen to the new channel, because
the new channel has a new btiochannel. I have to experiment with this
to be completely sure and see how DBus fd-passing deals with this, but
everything points that nothing will happen when closing the previous
get fd.
> If it was the case that we simply could not change the channel path naming, this behaviour should at least written very clearly in API.
>
>> In general, I think, guys, that we are thinking again in very estrange
>> situations. As we said in the Recife's meeting we should design the
>> implementation and the API for working with compliants devices, not
>> with buggy ones and also we have to simplify the use for the API,
>> making it simple for the application programmers in the most usual
>> cases not in the strange ones, that will happen very rarely.
>
> It's weekend, and playing devil's advocate is fun :P
>
> Seriously now, my objective is the same, avoiding that a perfectly sensible application act (closing fd after receiving a ChannelDeleted event) causing a race condition. And IMHO a condition that may happen with compliant devices as well.
Let's see what fd-passing is managing the fd and decide having this
data. Tomorrow I'll experiment with this and reply to the list with
the results.
Regards.
Jose
Hello,
> In that case, the problem is in the remote side, because the Bluetooth
> SIG certification requires the devices to support reconnections, so
> the problem is not in our side but in the remote side that isn't
> compliant with the standard. I think we don't have to change our
> implementation regarding buggy devices that don't follow the
> specification correctly.
I think an HDP device is NOT required to support reconnections. In HDP spec item 5.2.11 there is that bitmap in SDP record that says whether device supports reconnections and CSP.
> More over, the situation that you mention. When receiving a
> ChannelDeletion, the application shouldn't close the data channel,
> because the in the normal situation, the DBus object for the data
> channel will be removed, so no closing of the channel will be
> performed, the only thing that should happen is that the application
> will "forget" about this channel. When the second ChannelConnected is
> received, the application will typically perform an acquire that, in
> this case, will be very simple because the channel will be already
> connected and the fd will be transmitted.
So the application must follow a very specific behaviour when handling a ChannelDeleted signal, and worse yet, it must do it to fix a problem that we could fix simply by changing the way channel paths are named.
If it was the case that we simply could not change the channel path naming, this behaviour should at least written very clearly in API.
> In general, I think, guys, that we are thinking again in very estrange
> situations. As we said in the Recife's meeting we should design the
> implementation and the API for working with compliants devices, not
> with buggy ones and also we have to simplify the use for the API,
> making it simple for the application programmers in the most usual
> cases not in the strange ones, that will happen very rarely.
It's weekend, and playing devil's advocate is fun :P
Seriously now, my objective is the same, avoiding that a perfectly sensible application act (closing fd after receiving a ChannelDeleted event) causing a race condition. And IMHO a condition that may happen with compliant devices as well.
2010/10/23 Elvis Pf?tzenreuter <[email protected]>:
>> 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.
In that case, the problem is in the remote side, because the Bluetooth
SIG certification requires the devices to support reconnections, so
the problem is not in our side but in the remote side that isn't
compliant with the standard. I think we don't have to change our
implementation regarding buggy devices that don't follow the
specification correctly.
>
> Anyway, MDL aborts are expected to be rare, so the actual problem won't be seen often in practice.
In the other hand is this reason you mention, this is a very estrange
situation, so I don't think that the behaviour that we take will be
very important. In fact I don't think that this situation will happen
ever. In the case of the oximeter if it doesn't reconnect data
channels I think that it won't never send an abort or any other
abnormal command.
>
> 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.
I don't think that this naming is a problem. Think that using the same
id that the real channel is using guarantees us that all the active
channels are using unique IDs in a very "cheap" way, because is MCAP
who's dealing with the id's assignment.
More over, the situation that you mention. When receiving a
ChannelDeletion, the application shouldn't close the data channel,
because the in the normal situation, the DBus object for the data
channel will be removed, so no closing of the channel will be
performed, the only thing that should happen is that the application
will "forget" about this channel. When the second ChannelConnected is
received, the application will typically perform an acquire that, in
this case, will be very simple because the channel will be already
connected and the fd will be transmitted.
In general, I think, guys, that we are thinking again in very estrange
situations. As we said in the Recife's meeting we should design the
implementation and the API for working with compliants devices, not
with buggy ones and also we have to simplify the use for the API,
making it simple for the application programmers in the most usual
cases not in the strange ones, that will happen very rarely.
Regards.
2010/10/24 Santiago Carot <[email protected]>:
> Hi,
>
> 2010/10/23 Elvis Pf?tzenreuter <[email protected]>:
>>> 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).
>
> sure?
> Then you should think what happen with the First reliable data channel
> in case that you are running multiples IEEE specializations over the
> same HDP instance (that is pretty common in IEEE level). Remember that
> the First Relible data channel is used for IEEE association and
> confirmed event traffic. If you dont allow use that channel by other
> application it won't associate with the other device at IEEE layer.
> Please, think that with current HDP implementation you can develop
> IEEE agent specializations too, not only managers.
>
> HDP specification says:
> * The first Data Channel opened on a given MCL shall be a Reliable Data Channel.
> * Association traffic shall be carried on the first Reliable Data
> Channel that was
> opened on a given MCL.
>
> Next you are a text fragment copied from white paper (Alluding to the
> example where there are two applications on HDP):
> ?"...The right side of the diagram shows two devices that typically
> both use Reliable Data Channels. In this
> case, the devices may share a common Reliable Data Channel (and MDL)
> for all data or may optionally
> have separate MDLs for their data, but share the first Reliable Data
> Channel for IEEE association and
> confirmed event traffic..."
>
>
>>
>> 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.
>
> There are not only Nonin oximeter devices, we have a blood pressure
> that reconnect data channels, in the past we played with a weighing
> scale wich it was waiting for data channel connections, besides it is
> expected more complex devices such as electrocardiograms, and also you
> should think about what will happen if somebody uses this
> implementation to develop a health device specialization?, for
> example, I thinking in smartphones with sensors, etc... IMHO it is
> very presumptuous to make such assumptions about the future (may be I
> am too idealist) :P
>
>>
>> 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.
>
Sorry, please, ignore my last comment:
> That is a problem in remote side and applications shall to know how
You are right, I don't know exactly how we can address that problem,
may be we have to study this in deep.
Regards.
Hi,
2010/10/23 Elvis Pf?tzenreuter <[email protected]>:
>> 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).
sure?
Then you should think what happen with the First reliable data channel
in case that you are running multiples IEEE specializations over the
same HDP instance (that is pretty common in IEEE level). Remember that
the First Relible data channel is used for IEEE association and
confirmed event traffic. If you dont allow use that channel by other
application it won't associate with the other device at IEEE layer.
Please, think that with current HDP implementation you can develop
IEEE agent specializations too, not only managers.
HDP specification says:
* The first Data Channel opened on a given MCL shall be a Reliable Data Channel.
* Association traffic shall be carried on the first Reliable Data
Channel that was
opened on a given MCL.
Next you are a text fragment copied from white paper (Alluding to the
example where there are two applications on HDP):
"...The right side of the diagram shows two devices that typically
both use Reliable Data Channels. In this
case, the devices may share a common Reliable Data Channel (and MDL)
for all data or may optionally
have separate MDLs for their data, but share the first Reliable Data
Channel for IEEE association and
confirmed event traffic..."
>
> 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.
There are not only Nonin oximeter devices, we have a blood pressure
that reconnect data channels, in the past we played with a weighing
scale wich it was waiting for data channel connections, besides it is
expected more complex devices such as electrocardiograms, and also you
should think about what will happen if somebody uses this
implementation to develop a health device specialization?, for
example, I thinking in smartphones with sensors, etc... IMHO it is
very presumptuous to make such assumptions about the future (may be I
am too idealist) :P
>
> 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.
That is a problem in remote side and applications shall to know how
> 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.
Hi again,
2010/10/23 Santiago Carot <[email protected]>:
> Hi Elvis,
>
> 2010/10/23 Santiago Carot <[email protected]>:
>> Hi,
>>
>> 2010/10/22 Elvis Pf?tzenreuter <[email protected]>:
>>> Taking a look in the code, I saw that hdp_mcap_mdl_aborted_cb() emits a ChannelConnected signal.
>>>
>>> I understand that after an abort, the MDL still exists, and can be reconnected, so I understand the intention of informing the application that a channel has been "created". But I'm not sure that it is opportune.
>>>
>>> The first thing the application will do is trying to Acquire() the channel's file descriptor (that does not exist) and that triggers a reconnection attempt, from acceptor to initiator. While the most sensible thing (in my view) is waiting for the initiator to reconnect -- if it aborted, it must have a good reason, and it will probably reject the immediate call back.
>>>
>>
>> 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 found the example that I was trying to explain here in page 16 of
> the HDP whitepaper, there you can see two applications over HDP
> sharing the same data channel (one of them providing support to
> diferents device specializations).
>
Well, may be that above reference is not the best because in the
picture applications share the same MDEP too, but I think that it is
enough to see analogies.
>> That is the reason why HDP sends out a signal when a data channel has
>> been created.
>> Of course, the efficence of the protocol will depend on intelligence
>> of the programmer of the applications to take advantages of MCAP
>> reconnections. In any case, you will need to know when a data channel
>> has been created over the MCL (by you, or by other application).
>>
>> Regards,
>>
>> Santiago
>>
>
Hi Elvis,
2010/10/23 Santiago Carot <[email protected]>:
> Hi,
>
> 2010/10/22 Elvis Pf?tzenreuter <[email protected]>:
>> Taking a look in the code, I saw that hdp_mcap_mdl_aborted_cb() emits a ChannelConnected signal.
>>
>> I understand that after an abort, the MDL still exists, and can be reconnected, so I understand the intention of informing the application that a channel has been "created". But I'm not sure that it is opportune.
>>
>> The first thing the application will do is trying to Acquire() the channel's file descriptor (that does not exist) and that triggers a reconnection attempt, from acceptor to initiator. While the most sensible thing (in my view) is waiting for the initiator to reconnect -- if it aborted, it must have a good reason, and it will probably reject the immediate call back.
>>
>
> 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 found the example that I was trying to explain here in page 16 of
the HDP whitepaper, there you can see two applications over HDP
sharing the same data channel (one of them providing support to
diferents device specializations).
> That is the reason why HDP sends out a signal when a data channel has
> been created.
> Of course, the efficence of the protocol will depend on intelligence
> of the programmer of the applications to take advantages of MCAP
> reconnections. In any case, you will need to know when a data channel
> has been created over the MCL (by you, or by other application).
>
> Regards,
>
> Santiago
>
Hi,
2010/10/22 Elvis Pf?tzenreuter <[email protected]>:
> Taking a look in the code, I saw that hdp_mcap_mdl_aborted_cb() emits a ChannelConnected signal.
>
> I understand that after an abort, the MDL still exists, and can be reconnected, so I understand the intention of informing the application that a channel has been "created". But I'm not sure that it is opportune.
>
> The first thing the application will do is trying to Acquire() the channel's file descriptor (that does not exist) and that triggers a reconnection attempt, from acceptor to initiator. While the most sensible thing (in my view) is waiting for the initiator to reconnect -- if it aborted, it must have a good reason, and it will probably reject the immediate call back.
>
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.
That is the reason why HDP sends out a signal when a data channel has
been created.
Of course, the efficence of the protocol will depend on intelligence
of the programmer of the applications to take advantages of MCAP
reconnections. In any case, you will need to know when a data channel
has been created over the MCL (by you, or by other application).
Regards,
Santiago