linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Gustavo F. Padovan" <gustavo@padovan.org>
To: "Elvis Pfützenreuter" <epx@signove.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:49:19 -0300	[thread overview]
Message-ID: <20100507194919.GA4857@vigoh> (raw)
In-Reply-To: <82D1897F-4DEE-47F9-BD00-57087F182C3D@signove.com>

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

  parent reply	other threads:[~2010-05-07 19:49 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
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 [this message]
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=20100507194919.GA4857@vigoh \
    --to=gustavo@padovan.org \
    --cc=epx@signove.com \
    --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).