909883 - Support concurrent file transfers to different devices

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Thomas Zimmermann [:tzimmermann] [:tdz]]

We have more and more use cases where we want to transfer specific data, such as vcards, images, or videos, to other devices via BT. I think we currently have several limitations for doing that (one paired device at a time(?)). We should evaluate and discuss the necessary steps for resolving this problem.

Comment 1

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Some relevant bugs

  https://bugzilla.mozilla.org/show_bug.cgi?id=887534
  https://bugzilla.mozilla.org/show_bug.cgi?id=887663
  https://bugzilla.mozilla.org/show_bug.cgi?id=894320

Comment 2

[Eric Chou [:ericchou] [:echou]]

Hi Thomas,

Ben Tian has been working on bug 897782 for a while. The main idea of his solution is queueing file sharing requests in Gecko, so we won't report error to Gaia when users want to share files while there's still an ongoing transferring.

As for concurrent file transfer, we have had a bug (bug 806749) but I closed it for some reasons, mainly because the amount of connections may be limited by the capability of Bluetooth chip and Bluetooth stack. Please refer to bug 806749 comment 4 for more information.

- Eric

Comment 3

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Hi Eric,

Thanks for the information. The topic of multiple file transfers over BT has come up several times now in several contexts, such as VCARD transfers or NFC image sharing. I think that queuing file transfers should be sufficient for now to handle these use cases.

In the long run, I wouldn't completely give up on the idea of concurrent transfers however. If you have a long-running file transfer (lets say minutes) and want to quickly exchange VCARDs, queuing them is not an overly good user experience. 

Having concurrent file transfers is probably just a matter of not using global values and data structures in the relevant places? We can certainly slowly work towards that goal. Maybe we could keep one of these bug reports open, but set the priority to 'Enhancement'? What do you think?

Comment 4

[Eric Chou [:ericchou] [:echou]]

Hi Thomas,

> In the long run, I wouldn't completely give up on the idea of concurrent
> transfers however. If you have a long-running file transfer (lets say
> minutes) and want to quickly exchange VCARDs, queuing them is not an overly
> good user experience. 

Agree. In addition, yesterday I talked to EPM Joe about the queuing sending requests idea and he thought we should put this in FxOS v1.3 since it may need UX input. Just to let you know.

> 
> Having concurrent file transfers is probably just a matter of not using
> global values and data structures in the relevant places? 

I won't be too worried about implementation on our side under dom/bluetooth, however my main concern will still be the uncertainty of capability of Bluetooth stack and Bluetooth hardware. I was thinking maybe we can have a "max connections" limit to avoid bugs like "Trying to share files to 10 devices concurrently but failed" being reported.

> We can certainly slowly work towards that goal. Maybe we could keep one of these 
> bug reports open, but set the priority to 'Enhancement'? What do you think?

Sure. We can just use this bug as a beginning and discuss here. :)

- Eric

Comment 5

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Adding Ken, as it's related to NFC.

Comment 6

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Hi Eric,

That sound's very good.

> however my main concern will still be the uncertainty of capability of
> Bluetooth stack and Bluetooth hardware. I was thinking maybe we can have a
> "max connections" limit to avoid bugs like "Trying to share files to 10
> devices concurrently but failed" being reported.

Limiting the maximum number of connections sounds like a sensible thing to do. Something I had in mind was that we could also decide by looking at the file sizes. If we have a long running file transfer and want to transfer a small file, we'd send it concurrently. If we'd want to send another large file, we'd queue.

I'm sure we could work out some heuristics for selecting the best strategy. And if the chip set is crappy we'd still be able to switch to queuing exclusivly.

Comment 7

[Ben Tian (inactive)]

Revise this bug title since bug 897782 for multiple file transfer has already been landed.

Comment 9

[BMO Automation]

Firefox OS is not being worked on