Data transmission and reconnections in HDP

Data transmission and reconnections in HDP

[José Antonio Santos Cadenas]

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.

Re: Data transmission and reconnections in HDP

[Gustavo F. Padovan]

Hi José,

* José Antonio Santos Cadenas <jcaden@libresoft.es> [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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Gustavo F. Padovan
http://padovan.org

Re: Data transmission and reconnections in HDP

[João Paulo Rechi Vita]

Hello Jose!

On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> Hi José,
>
> * José Antonio Santos Cadenas <jcaden@libresoft.es> [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/

Re: Data transmission and reconnections in HDP

[Santiago Carot-Nemesio]

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 <gustavo@padovan.org> wrote:
> > Hi José,
> >
> > * José Antonio Santos Cadenas <jcaden@libresoft.es> [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.

Re: Data transmission and reconnections in HDP

[João Paulo Rechi Vita]

Hello Santiago!

2010/5/7 Santiago Carot-Nemesio <scarot@libresoft.es>:
> 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 <gustavo@padovan.org> wrote:
>> > Hi José,
>> >
>> > * José Antonio Santos Cadenas <jcaden@libresoft.es> [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/

Re: Data transmission and reconnections in HDP

[Gustavo F. Padovan]

Hi all,

* João Paulo Rechi Vita <jprvita@gmail.com> [2010-05-07 15:25:17 -0300]:

> Hello Jose!
> 
> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> > Hi José,
> >
> > * José Antonio Santos Cadenas <jcaden@libresoft.es> [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

Re: Data transmission and reconnections in HDP

[João Paulo Rechi Vita]

On Fri, May 7, 2010 at 18:18, Elvis Pfützenreuter <epx@signove.com> wrote:
>
>>> 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. ;)
>
> Ok, I think we have a conclusion, the Libresoft guys were right all along.
>
> Since the IEEE protocol over the data channel is a request-indication guy, one of these possible scenarios will happen:
>
> a) send request, receive indication
> b) send request, socket closes
> c) send request, socket closes, MCAP connection dropped feedback
>
> Our problem is the (b) case. We don't know if the request arrived at the other end. So the application must be able to replay the request upon receving the new socket for the same data channel. The reconnection itself does not need to be notified (though fd replacement is a clear sign that it happened.). And best of all, we can pass the L2CAP socket itself, not a pipe.
>
> The only thing that must be crystal clear in API is: the fd socket may get invalid anytime, and the application must be able to replay the pending requests. The reconnection is "transparent" pero no mucho :)
>

Automatic reconnection should happen only in the case HDP has
disconnected the transport for power-saving, because the data layer is
idle, doesn't it? So will (b) ever happen? In the case the connection
is dropped (loss of signal etc) the data layer should always be
notified IMO (case c).

-- 
João Paulo Rechi Vita
http://jprvita.wordpress.com/

Re: Data transmission and reconnections in HDP

[Elvis Pfützenreuter]

> 
> Automatic reconnection should happen only in the case HDP has
> disconnected the transport for power-saving, because the data layer is
> idle, doesn't it? So will (b) ever happen? In the case the connection
> is dropped (loss of signal etc) the data layer should always be
> notified IMO (case c).

MCAP spec says that 

"Because the Source and Sink assign a unique MDL ID when a new MDL is formed, using this same ID later allows a reconnection to the same context after they are intentionally closed or unintentionally broken (possibly from interference or temporarily moving out of range)." (Page 27)

HDP spec always talks mentions "reconnection" and "power saving" near each other, but I guess it is in a broader context (not having to renegotiate every data channel after an involuntary break-up also saves power).

Re: Data transmission and reconnections in HDP

[José Antonio Santos Cadenas]

El Monday 10 May 2010 04:31:22 Elvis Pfützenreuter escribió:
> > 
> > Automatic reconnection should happen only in the case HDP has
> > disconnected the transport for power-saving, because the data layer is
> > idle, doesn't it? So will (b) ever happen? In the case the connection
> > is dropped (loss of signal etc) the data layer should always be
> > notified IMO (case c).
> 
> MCAP spec says that 
> 
> "Because the Source and Sink assign a unique MDL ID when a new MDL is formed, using this same ID later allows a reconnection to the same context after they are intentionally 
closed or unintentionally broken (possibly from interference or temporarily moving out of range)." (Page 27)
> 
> HDP spec always talks mentions "reconnection" and "power saving" near each other, but I guess it is in a broader context (not having to renegotiate every data channel after an 
involuntary break-up also saves power).--

Completely agree with this, reconnections should be performed  until the 
data channel is deleted (this mdlid is no valid anymore for reconnections)
or until one of the sessions is closed, the remote or the local.

Re: Data transmission and reconnections in HDP

[José Antonio Santos Cadenas]

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 <gustavo@padovan.org> wrote:
> > Hi José,
> >
> > * José Antonio Santos Cadenas <jcaden@libresoft.es> [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?)
> >>
> 
> 

Re: Data transmission and reconnections in HDP

[Gustavo F. Padovan]

Hi Elvis,

* Elvis Pfützenreuter <epx@signove.com> [2010-05-07 10:20:59 -0300]:

> 
> >> 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.
> 
> Actually the worry is not whether D-BUS can lose the data midway (it can't indeed), but if the L2CAP connection closes and the application is not sure about the last message having been sent.

If the close is requested by the local side I guarantee on ERTM that
close will return only after receive the ack of the last packet sent
or some error happens and the channel get closed anyway -- I have to
check if I report a error in this case. ERTM has to guarantee the case
you are talking about, since it is reliable.

Also I still have to check the case when the remote side requests a
disconnect. I'm adding these stuff to my todo list an I'll work on it
soon.

It's nice that we are going to have real users to my ERTM code. ;-)

Regards,

-- 
Gustavo F. Padovan
http://padovan.org

Re: Data transmission and reconnections in HDP

[Elvis Pfützenreuter]

> 
> Also I still have to check the case when the remote side requests a
> disconnect. I'm adding these stuff to my todo list an I'll work on it
> soon.

I imagined the case when send(msg) returns, the msg is still in output buffer and then the connection drops due e.g. to faint signal (not voluntary close). (I understand ERTM guarantees atomic delivery of message, but I don't think it blocks send() until the message is safely at the other side.)

Re: Data transmission and reconnections in HDP

[Gustavo F. Padovan]

* Elvis Pfützenreuter <epx@signove.com> [2010-05-07 16:55:13 -0300]:

> > 
> > Also I still have to check the case when the remote side requests a
> > disconnect. I'm adding these stuff to my todo list an I'll work on it
> > soon.
> 
> I imagined the case when send(msg) returns, the msg is still in output buffer and then the connection drops due e.g. to faint signal (not voluntary close). (I understand ERTM guarantees atomic delivery of message, but I don't think it blocks send() until the message is safely at the other side.)

The sock stays connected, if such error happen it will be disconnected
and error will be reported. Also blocking on sending doesn't guarantee
if you data will be delivered.

-- 
Gustavo F. Padovan
http://padovan.org