Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow sending large files #7

Closed
dbrgn opened this issue Feb 15, 2017 · 4 comments · Fixed by #769
Closed

Allow sending large files #7

dbrgn opened this issue Feb 15, 2017 · 4 comments · Fixed by #769
Assignees
@lgrahl
Labels
app-update Requires an app update bug It's a bug! os-android Concerns the Android app

Comments

@dbrgn
Copy link
Contributor

dbrgn commented Feb 15, 2017

Currently file size is limited to 15 MiB because of an issue with WebRTC DataChannel buffering:

saltyrtc/saltyrtc-task-webrtc-js#9
@dbrgn dbrgn added the bug It's a bug! label Feb 15, 2017
@dbrgn dbrgn self-assigned this Feb 15, 2017
@ovalseven8 ovalseven8 mentioned this issue Mar 6, 2017
Closed
@ovalseven8
Copy link
Contributor

Is there any ETA? When I like to send a video that's usually not possible because of this 15 MiB limit.

@dbrgn
Copy link
Contributor Author

dbrgn commented Dec 15, 2017

I'm also annoyed by this every once in a while, so it's definitely on our list of planned things to do :)

@lgrahl
Copy link
Contributor

lgrahl commented Dec 15, 2017

This is really annoying to fix as well as the data channel API is just so clunky. We have a low water mark event which will tell us when to unpause sending but there's no high water mark event which tells us when to pause sending. The spec says that send should throw an OperationError in case no buffer space is available. But as far as I can recall, Chrome just closes the data channel and Firefox endlessly buffers your data until you're OOM (which isn't optimal either because of backpressure but it's fine for our use case). Other than that, the buffered amount low event only raises if the buffer is completely empty in Chrome-based implementations. This means, sending will slow start again and has other issues which are a throughput killer, see sctplab/usrsctp#142.

@lgrahl lgrahl mentioned this issue Dec 17, 2017
Closed
@lgrahl lgrahl assigned lgrahl and unassigned dbrgn Sep 24, 2018
@lgrahl
Copy link
Contributor

lgrahl commented Sep 24, 2018

High on my to do list. 😝

@lgrahl lgrahl mentioned this issue Mar 5, 2019
Merged
3 tasks
lgrahl added a commit that referenced this issue Mar 5, 2019
@lgrahl
Add helper classes that ease the use of the data channel flow control
63ce93d 
Preliminary work for #7
lgrahl added a commit that referenced this issue Mar 6, 2019
@lgrahl
Add helper classes that ease the use of the data channel flow control
dc5bd73 
Preliminary work for #7
lgrahl added a commit that referenced this issue Mar 6, 2019
@lgrahl
Add helper classes that ease the use of the data channel flow control
f8e75a9 
Preliminary work for #7
@lgrahl lgrahl added app-update Requires an app update os-android Concerns the Android app labels Jul 22, 2019
lgrahl added a commit that referenced this issue Aug 14, 2019
@lgrahl
Update to new SaltyRTC WebRTC Task API
c608aa6 
This update allows us to control data channels ourselves and thus apply
a sender-side flow control which prevents data channels from becoming
closed (#594).

This is also preliminary work for #7.

Further changes:

- Bump SaltyRTC client and WebRTC task dependencies
- Use chunking API v2
- Add helper classes that ease the use of the data channel flow control
lgrahl added a commit that referenced this issue Aug 19, 2019
@lgrahl
Update to new SaltyRTC WebRTC Task API
04d215f 
This update allows us to control data channels ourselves and thus apply
a sender-side flow control which prevents data channels from becoming
closed (#594).

This is also preliminary work for #7.

Further changes:

- Bump SaltyRTC client and WebRTC task dependencies
- Use chunking API v2
- Add helper classes that ease the use of the data channel flow control
- Allow to send files > 15 MiB towards Android
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lgrahl lgrahl

Labels
app-update Requires an app update bug It's a bug! os-android Concerns the Android app
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Flow controlled data channels threema-ch/threema-web
3 participants
@dbrgn @lgrahl @ovalseven8