2013-03-15 3 views
6

Я экспериментирую с webRTC, и кажется, что существует произвольное ограничение количества байтов, которое может быть отправлено в каждом сообщении. This guy, пример которого я использовал, выбирал предел в 100 (плюс несколько) байтов. В моих тестах он близок к 200 байтам. Однако от чтения по TCP и UDP эти протоколы поддерживают пакеты размером около 65 кбайт и даже при учете MTU для разных типов сетей, все равно должно быть намного больше свободного места, чем ~ 200 байт.Каков максимальный размер сообщений канала данных webRTC?

Единственный источник, который я нашел, который упоминает жесткий предел, - this WebRTC Data Channel Protocol draft, но он говорит только о TBD.

Так что мои вопросы:

  1. , если есть какой-либо источник, который определяет текущее сообщение предельного размера в любом браузере?
  2. если я могу предположить, что предел всегда один и тот же, а если нет, то каким-либо образом мое приложение может быть проинформировано о лимите?
+0

В случае, если кто-то найдет это с аналогичными проблемами, я нашел некоторые почти связанные данные. В настоящее время chrome ограничивает трафик примерно до 3 кбит/с вместо обнаружения перегрузок. Этот предел считается удаленным, когда они выяснили, как его обнаружить. Я не уверен, что если проблема, которую я испытал, вызвана этим. –

+0

Я занимаюсь той же проблемой. Есть ли предел в firefox? – charlypu

+0

Firefox, похоже, не имеет этого ограничения и даже поддерживает отправку Blobs. Но с firefox я не могу установить соединение между вкладками/браузерами вместо ... –

ответ

5

Проект sharefest нашел путь вокруг дросселирования скорости - вы можете изменить исходящее предложение, чтобы изменить настройку полосы пропускания (в http://www.ietf.org/rfc/rfc2327.txt)

Подробности здесь: https://github.com/Peer5/ShareFest/blob/master/public/js/peerConnectionImplChrome.js#L201

Из моего собственного опыта вы» re все еще ограничено ~ 800 байт на сообщение.

+0

Спасибо! Я попробую, как только у меня появится шанс. –

+0

Кажется, что нужно работать! Большие файлы разбили вкладку, но я предполагаю, что это вызвано моей конкретной реализацией. –

+0

Вы пытаетесь загрузить весь файл сразу? Вместо этого используйте slicing для чтения файла по бит: http://www.html5rocks.com/en/tutorials/file/dndfiles/ для обзора нарезки и моего собственного проекта http://hcliff.github.com/ampere для более связанных с работой с большими файлами и webrtc :) – hcliff

0

Я тестировал передачу jpegs на chrome 57 по каналу данных, и сообщения до 64k, похоже, теперь надежны.

Канал данных webRTC имеет механизм надежности, он использует SCTP через DTLS (через UDP). SCTP позволяет вам устанавливать надёжность и порядок заказа, но по умолчанию WebRTC использует упорядоченный + надежный - это означает, что вы получаете аналогичную семантику TCP - за исключением того, что границы сообщений сохраняются - по крайней мере теоретически.

На практике Chrome может доставлять частичные сообщения до javascript, если у них заканчивается свободное пространство, поэтому лучше всего проверить, что у вас есть полное сообщение перед его обработкой.

Смежные вопросы