On Fri, May 7, 2010 at 18:18, Elvis Pfützenreuter <epx@xxxxxxxxxxx> 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
