Hi all,
I start this thread to discuss the alternatives to move the data from the
application to the l2cap socket in HDP. Till now we have the following
alternatives (please, add more if we missed something)
Reconnections options:
Option 1: Implicit reconnections: The application is not concern about the
disconnections or reconnections of the data channel until it is deleted.
We prefer this option because fixes more with a manager philosophy. A
20601 manager sould not perceive temporal disconnections because this way can
hold it state if it perceives a disconnection, next time it reconnects it will
need to exchange again apdus for association.
Option 2: Reconnections by the application. The applications are notified when
a data channel is disconnected and should perform a reconnection before using
it again.
Data transmission options:
Option 1: Fd_passing the l2cap socket of the data channel to the client. The
problem with this is that some data can be lost by d-bus if the channel is
disconnected. (We have to check how fd-passing works).
Option 2: Fd_passing a pipe and HDP will write the data in the l2cap data
chanel socket. The problem with this is that we need 2 pipes for each data
channel, but no data will be lost because HDP controls the data flow with the
sockets and resend data not correctly sent.
We think that the easier way for implicit reconnections is option 2.
Because the application can always write on the socket it have (the pipe).
Once written, the HDP layer tries to write it in the l2cap socket, if it
fails, perform a reconnection operation over the data channel.
Option 3: Transmiting the data by d-bus. We think that this option is bad for
d-bus, because of the overload of the system bus.
Option 4: Other IPC alternatives (more alternative here?)
Regards.
El Friday 07 May 2010 20:25:17 Jo?o Paulo Rechi Vita escribi?:
> Hello Jose!
>
> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <[email protected]> wrote:
> > Hi Jos?,
> >
> > * Jos? Antonio Santos Cadenas <[email protected]> [2010-05-07 13:02:36 +0200]:
> >
> >> Hi all,
> >>
> >> I start this thread to discuss the alternatives to move the data from the
> >> application to the l2cap socket in HDP. Till now we have the following
> >> alternatives (please, add more if we missed something)
> >>
> >> Reconnections options:
> >>
> >> Option 1: Implicit reconnections: The application is not concern about the
> >> disconnections or reconnections of the data channel until it is deleted.
> >>
> >> We prefer this option because fixes more with a manager philosophy. A
> >> 20601 manager sould not perceive temporal disconnections because this way can
> >> hold it state if it perceives a disconnection, next time it reconnects it will
> >> need to exchange again apdus for association.
> >>
> >> Option 2: Reconnections by the application. The applications are notified when
> >> a data channel is disconnected and should perform a reconnection before using
> >> it again.
> >>
>
> The HDP Implementation Guidance Whitepaper clearly states that
> transport (HDP) disconnection / reconnection should be transparent for
> the data layer (IEEE 11073-20601), so I guess option 2 here would
> break the spec.
>
> >> Data transmission options:
> >>
> >> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
> >> problem with this is that some data can be lost by d-bus if the channel is
> >> disconnected. (We have to check how fd-passing works).
> >
> > DBus just pass the fd and then don't touch the fd anymore, data can't be
> > lost by DBus.
> >
>
> I guess the problem Jose tried to address here is the case that HDP
> had temporarily disconnected the data channel and then the application
> try to write to the FD (which will be closed). Some data may be lost
> by the application on this process.
That's exactly what I tried to expose. If you do fd-passing with the l2cap socket, it
is possible that the client writes data in a closed socket. If HDP fd-pass a pipe socket,
the client will write on the pipe, this way the client perceives just one file descriptor
which is exactly what we wanted if reconnections are implicit.
>
> >>
> >> Option 2: Fd_passing a pipe and HDP will write the data in the l2cap data
> >> chanel socket. The problem with this is that we need 2 pipes for each data
> >> channel, but no data will be lost because HDP controls the data flow with the
> >> sockets and resend data not correctly sent.
> >>
> >> We think that the easier way for implicit reconnections is option 2.
> >> Because the application can always write on the socket it have (the pipe).
> >> Once written, the HDP layer tries to write it in the l2cap socket, if it
> >> fails, perform a reconnection operation over the data channel.
> >>
>
> Considering the drawbacks of the other alternatives and taking into
> account that implicit reconnection is the right approach, this seems
> the better option. I can't see any problems on having 2 pipes per data
> channel, but I personally have never worked with splice directly so I
> can't address much issues of this approach.
That's the best option for us too. As I said above, this way the client perceives
the same socket during the whole live of the connection, perfect for
implicit reconnections.
>
> >> Option 3: Transmiting the data by d-bus. We think that this option is bad for
> >> d-bus, because of the overload of the system bus.
> >
> > Pretty bad ;)
> >
>
> As Gustavo said, transmitting data over d-bus would be very bad. On
> some embedded platforms d-bus can be really slow and even for the
> desktop case this is unnecessary overhead.
>
> >>
> >> Option 4: Other IPC alternatives (more alternative here?)
> >>
>
>
Hi all,
* Jo?o Paulo Rechi Vita <[email protected]> [2010-05-07 15:25:17 -0300]:
> Hello Jose!
>
> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <[email protected]> wrote:
> > Hi Jos?,
> >
> > * Jos? Antonio Santos Cadenas <[email protected]> [2010-05-07 13:02:36 +0200]:
> >
> >> Hi all,
> >>
> >> I start this thread to discuss the alternatives to move the data from the
> >> application to the l2cap socket in HDP. Till now we have the following
> >> alternatives (please, add more if we missed something)
> >>
> >> Reconnections options:
> >>
> >> ?Option 1: Implicit reconnections: The application is not concern about the
> >> disconnections or reconnections of the data channel until it is deleted.
> >>
> >> ? ? ? We prefer this option because fixes more with a manager philosophy. A
> >> 20601 manager sould not perceive temporal disconnections because this way can
> >> hold it state if it perceives a disconnection, next time it reconnects it will
> >> need to exchange again apdus for association.
> >>
> >> ?Option 2: Reconnections by the application. The applications are notified when
> >> a data channel is disconnected and should perform a reconnection before using
> >> it again.
> >>
>
> The HDP Implementation Guidance Whitepaper clearly states that
> transport (HDP) disconnection / reconnection should be transparent for
> the data layer (IEEE 11073-20601), so I guess option 2 here would
> break the spec.
>
> >> Data transmission options:
> >>
> >> ?Option 1: Fd_passing the l2cap socket of the data channel to the client. The
> >> problem with this is that some data can be lost by d-bus if the channel is
> >> disconnected. (We have to check how fd-passing works).
> >
> > DBus just pass the fd and then don't touch the fd anymore, data can't be
> > lost by DBus.
> >
>
> I guess the problem Jose tried to address here is the case that HDP
> had temporarily disconnected the data channel and then the application
> try to write to the FD (which will be closed). Some data may be lost
> by the application on this process.
If you are using Streming Mode you really don't care, if ERTM an error
will be reported and the application will get notified. ;)
--
Gustavo F. Padovan
http://padovan.org
Hello Santiago!
2010/5/7 Santiago Carot-Nemesio <[email protected]>:
> Hi João Paul,
>
> El vie, 07-05-2010 a las 15:25 -0300, João Paulo Rechi Vita escribió:
>> Hello Jose!
>>
>> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <[email protected]> wrote:
>> > Hi José,
>> >
>> > * José Antonio Santos Cadenas <[email protected]> [2010-05-07 13:02:36 +0200]:
>> >
>> >> Hi all,
>> >>
>> >> I start this thread to discuss the alternatives to move the data from the
>> >> application to the l2cap socket in HDP. Till now we have the following
>> >> alternatives (please, add more if we missed something)
>> >>
>> >> Reconnections options:
>> >>
>> >> Option 1: Implicit reconnections: The application is not concern about the
>> >> disconnections or reconnections of the data channel until it is deleted.
>> >>
>> >> We prefer this option because fixes more with a manager philosophy. A
>> >> 20601 manager sould not perceive temporal disconnections because this way can
>> >> hold it state if it perceives a disconnection, next time it reconnects it will
>> >> need to exchange again apdus for association.
>> >>
>> >> Option 2: Reconnections by the application. The applications are notified when
>> >> a data channel is disconnected and should perform a reconnection before using
>> >> it again.
>> >>
>>
>> The HDP Implementation Guidance Whitepaper clearly states that
>> transport (HDP) disconnection / reconnection should be transparent for
>> the data layer (IEEE 11073-20601), so I guess option 2 here would
>> break the spec.
>
> You're rigth, we consider that option 1 is the best approach. But it's
> better try get consensus ;)
> In addition, option 2 pass MCAP logic to application layer
> (connection-reconnection), and 11073-20601 should be independent of such
> transport specific characteristics.
>
My main concern here is not about which one is the best approach, but
about specification-compliance. Sometimes we may want to deviate a bit
from the spec if this provides a big performance gain or so, but it
has to be evaluated with much caution, since it can compromise
qualification with the Bluetooth SIG (on some cases for the whole
stack). I may have misread the spec and it might have left this
approach 2 as an option, so please correct me in this case. But if
not, I guess approach should not be considered.
--
João Paulo Rechi Vita
http://jprvita.wordpress.com/
Hi João Paul,
El vie, 07-05-2010 a las 15:25 -0300, João Paulo Rechi Vita escribió:
> Hello Jose!
>
> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <[email protected]> wrote:
> > Hi José,
> >
> > * José Antonio Santos Cadenas <[email protected]> [2010-05-07 13:02:36 +0200]:
> >
> >> Hi all,
> >>
> >> I start this thread to discuss the alternatives to move the data from the
> >> application to the l2cap socket in HDP. Till now we have the following
> >> alternatives (please, add more if we missed something)
> >>
> >> Reconnections options:
> >>
> >> Option 1: Implicit reconnections: The application is not concern about the
> >> disconnections or reconnections of the data channel until it is deleted.
> >>
> >> We prefer this option because fixes more with a manager philosophy. A
> >> 20601 manager sould not perceive temporal disconnections because this way can
> >> hold it state if it perceives a disconnection, next time it reconnects it will
> >> need to exchange again apdus for association.
> >>
> >> Option 2: Reconnections by the application. The applications are notified when
> >> a data channel is disconnected and should perform a reconnection before using
> >> it again.
> >>
>
> The HDP Implementation Guidance Whitepaper clearly states that
> transport (HDP) disconnection / reconnection should be transparent for
> the data layer (IEEE 11073-20601), so I guess option 2 here would
> break the spec.
You're rigth, we consider that option 1 is the best approach. But it's
better try get consensus ;)
In addition, option 2 pass MCAP logic to application layer
(connection-reconnection), and 11073-20601 should be independent of such
transport specific characteristics.
>
> >> Data transmission options:
> >>
> >> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
> >> problem with this is that some data can be lost by d-bus if the channel is
> >> disconnected. (We have to check how fd-passing works).
> >
> > DBus just pass the fd and then don't touch the fd anymore, data can't be
> > lost by DBus.
> >
>
> I guess the problem Jose tried to address here is the case that HDP
> had temporarily disconnected the data channel and then the application
> try to write to the FD (which will be closed). Some data may be lost
> by the application on this process.
>
> >>
> >> Option 2: Fd_passing a pipe and HDP will write the data in the l2cap data
> >> chanel socket. The problem with this is that we need 2 pipes for each data
> >> channel, but no data will be lost because HDP controls the data flow with the
> >> sockets and resend data not correctly sent.
> >>
> >> We think that the easier way for implicit reconnections is option 2.
> >> Because the application can always write on the socket it have (the pipe).
> >> Once written, the HDP layer tries to write it in the l2cap socket, if it
> >> fails, perform a reconnection operation over the data channel.
> >>
>
> Considering the drawbacks of the other alternatives and taking into
> account that implicit reconnection is the right approach, this seems
> the better option. I can't see any problems on having 2 pipes per data
> channel, but I personally have never worked with splice directly so I
> can't address much issues of this approach.
We are considering this approach depending of comments got from this
thread, it isn't a final design yet... but may be, we need study more
alternatives.
>
> >> Option 3: Transmiting the data by d-bus. We think that this option is bad for
> >> d-bus, because of the overload of the system bus.
> >
> > Pretty bad ;)
> >
>
> As Gustavo said, transmitting data over d-bus would be very bad. On
> some embedded platforms d-bus can be really slow and even for the
> desktop case this is unnecessary overhead.
We descarted this option from first time, but it appeared in other
e-mail so we should search consensus here too.
Thank a lot for your comments.
Best regards.
Hello Jose!
On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <[email protected]> wrote:
> Hi José,
>
> * José Antonio Santos Cadenas <[email protected]> [2010-05-07 13:02:36 +0200]:
>
>> Hi all,
>>
>> I start this thread to discuss the alternatives to move the data from the
>> application to the l2cap socket in HDP. Till now we have the following
>> alternatives (please, add more if we missed something)
>>
>> Reconnections options:
>>
>> Option 1: Implicit reconnections: The application is not concern about the
>> disconnections or reconnections of the data channel until it is deleted.
>>
>> We prefer this option because fixes more with a manager philosophy. A
>> 20601 manager sould not perceive temporal disconnections because this way can
>> hold it state if it perceives a disconnection, next time it reconnects it will
>> need to exchange again apdus for association.
>>
>> Option 2: Reconnections by the application. The applications are notified when
>> a data channel is disconnected and should perform a reconnection before using
>> it again.
>>
The HDP Implementation Guidance Whitepaper clearly states that
transport (HDP) disconnection / reconnection should be transparent for
the data layer (IEEE 11073-20601), so I guess option 2 here would
break the spec.
>> Data transmission options:
>>
>> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
>> problem with this is that some data can be lost by d-bus if the channel is
>> disconnected. (We have to check how fd-passing works).
>
> DBus just pass the fd and then don't touch the fd anymore, data can't be
> lost by DBus.
>
I guess the problem Jose tried to address here is the case that HDP
had temporarily disconnected the data channel and then the application
try to write to the FD (which will be closed). Some data may be lost
by the application on this process.
>>
>> Option 2: Fd_passing a pipe and HDP will write the data in the l2cap data
>> chanel socket. The problem with this is that we need 2 pipes for each data
>> channel, but no data will be lost because HDP controls the data flow with the
>> sockets and resend data not correctly sent.
>>
>> We think that the easier way for implicit reconnections is option 2.
>> Because the application can always write on the socket it have (the pipe).
>> Once written, the HDP layer tries to write it in the l2cap socket, if it
>> fails, perform a reconnection operation over the data channel.
>>
Considering the drawbacks of the other alternatives and taking into
account that implicit reconnection is the right approach, this seems
the better option. I can't see any problems on having 2 pipes per data
channel, but I personally have never worked with splice directly so I
can't address much issues of this approach.
>> Option 3: Transmiting the data by d-bus. We think that this option is bad for
>> d-bus, because of the overload of the system bus.
>
> Pretty bad ;)
>
As Gustavo said, transmitting data over d-bus would be very bad. On
some embedded platforms d-bus can be really slow and even for the
desktop case this is unnecessary overhead.
>>
>> Option 4: Other IPC alternatives (more alternative here?)
>>
--
João Paulo Rechi Vita
http://jprvita.wordpress.com/
Hi Jos?,
* Jos? Antonio Santos Cadenas <[email protected]> [2010-05-07 13:02:36 +0200]:
> Hi all,
>
> I start this thread to discuss the alternatives to move the data from the
> application to the l2cap socket in HDP. Till now we have the following
> alternatives (please, add more if we missed something)
>
> Reconnections options:
>
> Option 1: Implicit reconnections: The application is not concern about the
> disconnections or reconnections of the data channel until it is deleted.
>
> We prefer this option because fixes more with a manager philosophy. A
> 20601 manager sould not perceive temporal disconnections because this way can
> hold it state if it perceives a disconnection, next time it reconnects it will
> need to exchange again apdus for association.
>
> Option 2: Reconnections by the application. The applications are notified when
> a data channel is disconnected and should perform a reconnection before using
> it again.
>
> Data transmission options:
>
> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
> problem with this is that some data can be lost by d-bus if the channel is
> disconnected. (We have to check how fd-passing works).
DBus just pass the fd and then don't touch the fd anymore, data can't be
lost by DBus.
>
> Option 2: Fd_passing a pipe and HDP will write the data in the l2cap data
> chanel socket. The problem with this is that we need 2 pipes for each data
> channel, but no data will be lost because HDP controls the data flow with the
> sockets and resend data not correctly sent.
>
> We think that the easier way for implicit reconnections is option 2.
> Because the application can always write on the socket it have (the pipe).
> Once written, the HDP layer tries to write it in the l2cap socket, if it
> fails, perform a reconnection operation over the data channel.
>
> Option 3: Transmiting the data by d-bus. We think that this option is bad for
> d-bus, because of the overload of the system bus.
Pretty bad ;)
>
> Option 4: Other IPC alternatives (more alternative here?)
>
> Regards.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://padovan.org