On Fri, May 7, 2010 at 18:18, Elvis Pfützenreuter <[email protected]> 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/
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.
>
> 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).