Hi Elvis,
* Elvis Pf?tzenreuter <[email protected]> [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
* Elvis Pf?tzenreuter <[email protected]> [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
>
> 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.)