CC
Eugene P.
Сделать собственный оператор буфферинга для flow, у которого будет какая-то функция определяющая конец пакета и отправляющая накопленные данные дальше
Можно примерно как вы это видите описать абстрактно
Size: a a a
2020 August 02
EP
@noraltavir на всякий случай имел в виду эту реализацию. Но, вероятно, вы можете и лучше что-то придумать https://dev.to/psfeng/a-story-of-building-a-custom-flow-operator-buffertimeout-4d95
AN
Eugene P.
@noraltavir на всякий случай имел в виду эту реализацию. Но, вероятно, вы можете и лучше что-то придумать https://dev.to/psfeng/a-story-of-building-a-custom-flow-operator-buffertimeout-4d95
С задержкой там все довольно тривиально. Ща, погодите, уже почти написал
AN
https://pastebin.com/dEs0Lj32 Не тестил пока правда. И не получилось чанками копировать. Это можно только с однобуквенными разделитлями
AN
и это мультиплатформа :)
EP
Constantine Cerberus
Можно примерно как вы это видите описать абстрактно
Сложно с телефона. Как-то так, наверное
packetsFlow
.bufferTransform(
{rawData -> splitToPacketsWithState(rawData)},
{packet -> packet.isCompleted}
)
bufferTransform надо написать еще
packetsFlow
.bufferTransform(
{rawData -> splitToPacketsWithState(rawData)},
{packet -> packet.isCompleted}
)
bufferTransform надо написать еще
EP
на выходе он должен выдавать по одному пакету ну или список если надо
EP
Как референс я бы использовал bufferTimeout из статьи выше. Под капотом там ReceiveChannel
AN
Eugene P.
Как референс я бы использовал bufferTimeout из статьи выше. Под капотом там ReceiveChannel
Я выше скинул. Без промежуточных каналов. Тут не нужна асинхронная обработка.
CC
https://pastebin.com/dEs0Lj32 Не тестил пока правда. И не получилось чанками копировать. Это можно только с однобуквенными разделитлями
Интересное решение к та при повторном ините byteArrayout размер буфера не указали 16 стока
CC
Все время забываю про extension в котлине то постоянно их пишу то напроч отшыбает память про их существование
AN
Constantine Cerberus
Интересное решение к та при повторном ините byteArrayout размер буфера не указали 16 стока
о, спасиб. Сейчас еще потестю
CC
Eugene P.
на выходе он должен выдавать по одному пакету ну или список если надо
По одному пакету список не имеет в моем случае смысла держать нужно как можно приближенные к риал тайму
AN
Там еще по хорошему надо где-то перейти в однопоточный контекст, чтобы не было конкуррентного collect
AN
Все тесты проходят, можно пользоваться. Запушу в либу в следующей итерации. Плюс добавлю реализацию для TCP и для USB/RS232/RS485
CC
Все тесты проходят, можно пользоваться. Запушу в либу в следующей итерации. Плюс добавлю реализацию для TCP и для USB/RS232/RS485
Nice
EP
@noraltavir у вас там случаем нет того же бага, когда последний не полный элемент может не заэммититься? Или он должен игнориться?
AN
Игнорится, нет гарантии, что последний. Поток-то бесконечный. До дома дойду, тест скину
AM
Constantine Cerberus
По одному пакету список не имеет в моем случае смысла держать нужно как можно приближенные к риал тайму
Я, конечно, несколько со стороны за вашим общением наблюдаю, могу чего-то не понимать, но -- никто не мешает воткнуть ниже по флоу за бьющим на пакеты оператором буферизацию, если апстим должен выгребаться максимально быстро (буфер у железа маленький, к примеру), а даунстрим может иногда замедляться. Но, конечно, только при условии, что в среднем даунстрим всё равно будет быстрее апстрима.
AN
Я, конечно, несколько со стороны за вашим общением наблюдаю, могу чего-то не понимать, но -- никто не мешает воткнуть ниже по флоу за бьющим на пакеты оператором буферизацию, если апстим должен выгребаться максимально быстро (буфер у железа маленький, к примеру), а даунстрим может иногда замедляться. Но, конечно, только при условии, что в среднем даунстрим всё равно будет быстрее апстрима.
Там на самом деле если говорить про перформанс, по возможности надо все на месте обрабатывать, поскольку копирование в байт-массив - дорогое, а чистка памяти за ним еще дороже. А во Flow нельзя отправлять реюзабельные буферы, потому что они тогда утекают. Но это уже тонкости супер-оптимизации. Если кому интересно, велком в слак в #io дизайнить асинхронную реализацию.