linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "João Paulo Rechi Vita" <jprvita@gmail.com>
To: "Elvis Pfützenreuter" <epx@signove.com>
Cc: "Gustavo F. Padovan" <gustavo@padovan.org>,
	"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: Sun, 9 May 2010 22:08:04 -0300	[thread overview]
Message-ID: <u2paa32413d1005091808n54065c98o26ac89de1dde8770@mail.gmail.com> (raw)
In-Reply-To: <8D8F1AA1-A7C1-4636-BB75-1EF1A2E1A556@signove.com>

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/

  parent reply	other threads:[~2010-05-10  1:08 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
     [not found]       ` <8D8F1AA1-A7C1-4636-BB75-1EF1A2E1A556@signove.com>
2010-05-10  1:08         ` João Paulo Rechi Vita [this message]
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=u2paa32413d1005091808n54065c98o26ac89de1dde8770@mail.gmail.com \
    --to=jprvita@gmail.com \
    --cc=epx@signove.com \
    --cc=gustavo@padovan.org \
    --cc=jcaden@libresoft.es \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).