misyachniy (07.12.2021 09:26 - 10:06, просмотров: 121) ответил Argon на спасибо, интересно! краем глаза пробежал по описанию, байтстаффинг
- прикольная штука ) Я как раз не мог сообразить как
синхронизировать кадры, если буду изобретать велосипед )Ответы
-
- Спасибо, да, похоже на то что нужно. Многабукаф -> Argon(1 знак., 07.12.2021 09:52, ссылка)
- Какой-то лютый студенческий самопал. На первых же страницах: il-2(241 знак., 07.12.2021 12:35)
- И что смущает. Типичный прием. - RxTx(07.12.2021 16:24)
- Типичный - это когда делается подстановка, в результате которой управляющие коды встречаются только в тех местах, где должны. А тут - вместо одного кода поставили два, и там где его быть не должно. Вот пример правильной подстановки: il-2(998 знак., 08.12.2021 06:03)
- Смущает то, что вместо символа замещения escape-символа используется сам escape-символ. - Samx(08.12.2021 01:32)
- Кстати, этот документ скорее всего, не то, что было посоветовано выше. Вчитавшись можно обнаружить расшифровку: Smiley ® Secure Protocol (SSP). Тем не менее, что не устраивает в описании этого байт-стаффинга? В википедии описано аналогично. Argon(130 знак., 07.12.2021 12:44)
- И что смущает. Типичный прием. - RxTx(07.12.2021 16:24)
- Вариант от Максим. -> ir0407(1 знак., 07.12.2021 09:55, ссылка)
- Там про SSI, не SSP. Наверное что-то другое, и слова stuffing нет в
тексте. - Argon(07.12.2021 10:02)
- Зато простенько, со вкусом и с исходниками, которые под свои
хотелки завсегда
паламатьподправить можно.:) - ir0407(07.12.2021 10:35)- Да я уже на байт-стаффинг нацелился, уж очень не хочется учитывать
паузы при приеме. - Argon(07.12.2021 11:05)
- Паузы при приеме в протоколах типа "запрос-ответ" получаются
естественным путем, мастер вынужден ждать ответа, особенно в
каналах с общей средой, типа RS-485. Байт-стаффинг может быть
интересен, когда есть отдельные каналы для передачи и передаваемая
информация, в основном, формируется не в стиле запрос-ответ. - AlexBi(07.12.2021 12:12)
- Я, может, сгущаю краски, но один из моих девайсов теоретически
может взять паузу на середине своей передачи или приема. Так что
некоторые паузы не будут "естественными". - Argon(07.12.2021 12:21)
- Заложите эту паузу в свой протокол, т.е. пусть в протоколе будет
пауза больше чем может быть из-за особенностей девайса. А если
такие события редкие, то паузу можно не увеличивать, а такие
событие обрабатывать как дефекты связи. Все равно пауза при приеме
приведет к потере данных и это надо как-то обрабатывать. - AlexBi(07.12.2021 16:02)
- Предполагаю, что пауза не приведет к потере данных, а приведет к
лагу внутри пакета. Точные диапазоны этих пауз не знаю, допустим
порядка 300-500 мс, если в протокол закладывать такой порядок, то
это будет как-то совсем печально. Лучше уж я попытаюсь вот эти
относительно редкие события купировать "на лету" с помощью
паузоустойчивого протокола. Argon(95 знак., 07.12.2021 18:02)
- Пауза при передаче приведет к лагу, пауза при приеме приведет к
потере принятого у приемника. Или должен быть какой-то механизм,
останавливающий передатчик, пока приемник занят чем-то своим. Но
такого не планируется, как я понимаю, поэтому потери неизбежны и к
этому надо быть готовым. AlexBi(405 знак., 07.12.2021 19:29)
- Неа, пауза при приеме не должна привести к потере принятого у
приемника (одноплатник с ОС Android), ибо если я верно понимаю, то
данные таки примутся драйвером, который является частью ядра Linux.
В то время как сборщик мусора работает в среде dalvik (аналог Java
runtime) и тормозит мое приложение, которое и обрабатывает
прием-передачу. Argon(652 знак., 07.12.2021 20:38)
- А когда одноплатник будет передатчиком и будет сливать большой
объем данных (100К и более), то приемником можем наловить
нерегулярных пауз по той же самой причине с более чем нулевой
вероятностью. И лучше бы эти паузы победить логикой самого
протокола. Байт-стаффинг, по-моему то самое. - Argon(07.12.2021 20:54)
- Если там такой умный драйвер, то и при передаче пауз не будет, т.к. скорее всего передача делается так: в буфере готовится что надо передать, потом активируется драйвер, который передает весь буфер подряд, без пауз. AlexBi(386 знак., 07.12.2021 22:07)
- Я бы все же ввел какой-либо критерий по длительности паузы в передаче, как признак "битого" пакета данных. Для надежности. - rezident(07.12.2021 21:43)
- А когда одноплатник будет передатчиком и будет сливать большой
объем данных (100К и более), то приемником можем наловить
нерегулярных пауз по той же самой причине с более чем нулевой
вероятностью. И лучше бы эти паузы победить логикой самого
протокола. Байт-стаффинг, по-моему то самое. - Argon(07.12.2021 20:54)
- Неа, пауза при приеме не должна привести к потере принятого у
приемника (одноплатник с ОС Android), ибо если я верно понимаю, то
данные таки примутся драйвером, который является частью ядра Linux.
В то время как сборщик мусора работает в среде dalvik (аналог Java
runtime) и тормозит мое приложение, которое и обрабатывает
прием-передачу. Argon(652 знак., 07.12.2021 20:38)
- Пауза при передаче приведет к лагу, пауза при приеме приведет к
потере принятого у приемника. Или должен быть какой-то механизм,
останавливающий передатчик, пока приемник занят чем-то своим. Но
такого не планируется, как я понимаю, поэтому потери неизбежны и к
этому надо быть готовым. AlexBi(405 знак., 07.12.2021 19:29)
- Предполагаю, что пауза не приведет к потере данных, а приведет к
лагу внутри пакета. Точные диапазоны этих пауз не знаю, допустим
порядка 300-500 мс, если в протокол закладывать такой порядок, то
это будет как-то совсем печально. Лучше уж я попытаюсь вот эти
относительно редкие события купировать "на лету" с помощью
паузоустойчивого протокола. Argon(95 знак., 07.12.2021 18:02)
- Заложите эту паузу в свой протокол, т.е. пусть в протоколе будет
пауза больше чем может быть из-за особенностей девайса. А если
такие события редкие, то паузу можно не увеличивать, а такие
событие обрабатывать как дефекты связи. Все равно пауза при приеме
приведет к потере данных и это надо как-то обрабатывать. - AlexBi(07.12.2021 16:02)
- Я, может, сгущаю краски, но один из моих девайсов теоретически
может взять паузу на середине своей передачи или приема. Так что
некоторые паузы не будут "естественными". - Argon(07.12.2021 12:21)
- Паузы при приеме в протоколах типа "запрос-ответ" получаются
естественным путем, мастер вынужден ждать ответа, особенно в
каналах с общей средой, типа RS-485. Байт-стаффинг может быть
интересен, когда есть отдельные каналы для передачи и передаваемая
информация, в основном, формируется не в стиле запрос-ответ. - AlexBi(07.12.2021 12:12)
- Да я уже на байт-стаффинг нацелился, уж очень не хочется учитывать
паузы при приеме. - Argon(07.12.2021 11:05)
- Зато простенько, со вкусом и с исходниками, которые под свои
хотелки завсегда
- Там про SSI, не SSP. Наверное что-то другое, и слова stuffing нет в
тексте. - Argon(07.12.2021 10:02)
- Какой-то лютый студенческий самопал. На первых же страницах: il-2(241 знак., 07.12.2021 12:35)
- Где? - Kpoк(07.12.2021 09:30)
- Спасибо, да, похоже на то что нужно. Многабукаф -> Argon(1 знак., 07.12.2021 09:52, ссылка)