All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gustavo F. Padovan" <gustavo@padovan.org>
To: "João Paulo Rechi Vita" <jprvita@gmail.com>
Cc: "José Antonio Santos Cadenas" <jcaden@libresoft.es>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: Data transmission and reconnections in HDP
Date: Fri, 7 May 2010 16:57:04 -0300	[thread overview]
Message-ID: <20100507195704.GC4857@vigoh> (raw)
In-Reply-To: <k2taa32413d1005071125ob7ce6505q8bb2cc57a77f1c8f@mail.gmail.com>

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

  parent reply	other threads:[~2010-05-07 19:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-07 11:02 Data transmission and reconnections in HDP José Antonio Santos Cadenas
2010-05-07 12:08 ` Gustavo F. Padovan
2010-05-07 18:25   ` João Paulo Rechi Vita
2010-05-07 18:39     ` Santiago Carot-Nemesio
2010-05-07 18:49       ` João Paulo Rechi Vita
2010-05-07 19:57     ` Gustavo F. Padovan [this message]
     [not found]       ` <8D8F1AA1-A7C1-4636-BB75-1EF1A2E1A556@signove.com>
2010-05-10  1:08         ` João Paulo Rechi Vita
2010-05-10  2:31           ` Elvis Pfützenreuter
2010-05-10  7:53             ` José Antonio Santos Cadenas
2010-05-10  7:47     ` José Antonio Santos Cadenas
     [not found]   ` <82D1897F-4DEE-47F9-BD00-57087F182C3D@signove.com>
2010-05-07 19:49     ` Gustavo F. Padovan
2010-05-07 19:55       ` Elvis Pfützenreuter
2010-05-07 20:17         ` Gustavo F. Padovan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100507195704.GC4857@vigoh \
    --to=gustavo@padovan.org \
    --cc=jcaden@libresoft.es \
    --cc=jprvita@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.