Нужен отдельный котёл для эмбеддеров, делающих фрейминг в serial link (будь то uart или еще что-то) тупо на счётчике байтов, без какого либо стаффинга. Зато там црц есть. Если удастся его найти в потоке-то.
Помнишь я про "парсеры" рассказывал? От одной "системы сбора данных" ловил тисипишный поток. У него формально были хедеры у каждого сообщения, но у каждого типа сообщения -- свои, чтобы я не скучал. И протяженные. Ну то есть типа "Этот трек для тех кто носит широчи и шузы". Ну, думаю, блин, у вас же в софте есть режим "слать по UDP", включите же мне его! Хочу каждую мессагу получать отдельной датаграммой. Ага, щазз. Начинают приходить датаграммы, нарубленные на кусочки по минимал MTU, без какой-либо служебной информации, что называется перекрестись и склей в порядке прихода. Стыд-то какой... Стек это сам за тебя сделает, просто шли буфер. Тьфу. В результате вернулись к TCP. Поток приходится парсить регулярками Карл. Просто лимитируем макс длину буфера в который льется поток каким-нибудь мегабайтом, чтобы оно всю память не зохавало, и пытаемся регэкспом найти в этом гамне что-нибудь знакомое. Нашли? урезаем осетра и снова обнюхиваем буфер... БРРРРРРРР. Орден Сатаны. Как вспомню -- икаю.
Это, в целом, нормальный уровень средневекового зверства вариант нормы. Не вообще, а в исторической перспективе тысызыть. Юниксвей же; всё есть либо файл, либо текстовый стрим. Сетевая программа пишется как обычная, отлаживается путём печатания на терминале команд птичьего языка "ПРВД МДВД" / "ПТЧА ДЯЛ: <>", потом как есть засовывается под inetd и получается сетевой демон. Айтишный вариант каши из топора.
Соответственно, у нас есть TCP — это точно как пайп, во всём подобный локальному, только не локальный, а сетевой. И UDP для всякой мелкой неважной хуйни. Еще? А зачем что-то еще?
Так и жили. Границы сообщений в TCP при этом получались переводом строки — легко и естественно, как посрать сходить. Кому надо было гонять бинарные данные — изобретали... а вот не надо было гонять, вы бы еще кирпич высрать попробовали. Ну в общем да, всякие инструменты для жонглирования буферами, нахождения там границ сообщений и прочий доступ в первичный рот через вторичный, по пути стараемся не задеть гланды. Сам писал.
Потом молодому поколению программистов (это которые на единичку постарше нас с тобой) надоело так жить и они придумали SCTP, вебсокеты и несколько других штук где границы сообщений были, тысызыть, естественные, при сохранении общей потоковой структуры. Да что там, даже древний SSL/TLS уже общался сообщениями, надо было только через первый слой продраться и написать пакетизатор поверх голого TCP. Жалко что не до всех эти новшества дошли.
Но в общем и целом это и до сих пор большая боль, особенно если надо слать какие-либо структурированные данные. В XMPP, помню, какие-то трюки применялись для того чтобы xml слать кусками, причём именно нужными кусками. В json-rpc вообще не заморачиваются, и на каждое сообщение открывают новое соединение. Т.е. кончился жсончик, хоть их трёх байт — давай, досвидания. Следующее сообщение пойдет следующим коннектом, ну или пожалте бриться — т.е. изобретать свой фрейминг.
Другое дело что сериальному линку отсутствие фреймов _присуще_. Просто в силу нижележащей физики. А в тцп могли бы что-нибудь и придумать, учитывая количество прочих наворотов которые там есть.
А вот почему фрагментируется UDP — это загадка. Оно, по идее, должно быть прозрачно. Возможно тоже какой-нибудь эмбеддер привнёс своё понимание сути вещей.
UDP совершенно точно фрагментировался кривыми руками посылающей стороны, тут к гадалке не ходить. "мы где-то услышали, что не всяк пакет сквозь сеть пройдет, жрите вот". И сами же на коленке фрагментацию прикрутили. Я просто краем глаза интерфейс того чуда видел, из нег и выводы.
БЯЛ. Ну уж пару <msgid><seq-n> в начало датаграммы можно было хотя бы добавить.
Впрочем что в голове у отдельных представителей программерского племени можно только догадываться. Я еще давно в M.D. когда мы очередной движок к нашему поделию прикручивали наткнулся на.... в общем, там можно было запустить несколько задач разом, но колбэк который возвращал результаты никак задачу не идентифицировал. Я еще тогда напряг Каца чтобы он сходил до тех девелоперов и донёс до них идею добавить какой-нито пользовательский контекст и они даже сделали, но сопроводили комментарием в духе "не знаем зачем это вам, но если просите то вот".
Как бы базовая вещь, но в данном случае пришлось вот объяснять отдельно.
no subject
Date: 2021-07-23 03:20 pm (UTC)Что за стаффинг такой? (что такое црц я слава богу знаю, и не понаслышке)
no subject
Date: 2021-07-23 03:40 pm (UTC)и не-эмбедщиков тоже
Date: 2021-07-23 08:30 pm (UTC)От одной "системы сбора данных" ловил тисипишный поток. У него формально были хедеры у каждого сообщения, но у каждого типа сообщения -- свои, чтобы я не скучал. И протяженные. Ну то есть типа "Этот трек для тех кто носит широчи и шузы".
Ну, думаю, блин, у вас же в софте есть режим "слать по UDP", включите же мне его! Хочу каждую мессагу получать отдельной датаграммой. Ага, щазз.
Начинают приходить датаграммы, нарубленные на кусочки по минимал MTU, без какой-либо служебной информации, что называется перекрестись и склей в порядке прихода. Стыд-то какой... Стек это сам за тебя сделает, просто шли буфер. Тьфу.
В результате вернулись к TCP.
Поток приходится парсить регулярками Карл. Просто лимитируем макс длину буфера в который льется поток каким-нибудь мегабайтом, чтобы оно всю память не зохавало, и пытаемся регэкспом найти в этом гамне что-нибудь знакомое. Нашли? урезаем осетра и снова обнюхиваем буфер... БРРРРРРРР. Орден Сатаны.
Как вспомню -- икаю.
Re: и не-эмбедщиков тоже
Date: 2021-07-23 09:08 pm (UTC)нормальный уровень средневекового зверствавариант нормы. Не вообще, а в исторической перспективе тысызыть. Юниксвей же; всё есть либо файл, либо текстовый стрим. Сетевая программа пишется как обычная, отлаживается путём печатания на терминале команд птичьего языка "ПРВД МДВД" / "ПТЧА ДЯЛ: <>", потом как есть засовывается под inetd и получается сетевой демон. Айтишный вариант каши из топора.Соответственно, у нас есть TCP — это точно как пайп, во всём подобный локальному, только не локальный, а сетевой. И UDP для всякой мелкой неважной хуйни. Еще? А зачем что-то еще?
Так и жили. Границы сообщений в TCP при этом получались переводом строки — легко и естественно, как посрать сходить. Кому надо было гонять бинарные данные — изобретали... а вот не надо было гонять, вы бы еще кирпич высрать попробовали. Ну в общем да, всякие инструменты для жонглирования буферами, нахождения там границ сообщений и прочий доступ в первичный рот через вторичный, по пути стараемся не задеть гланды. Сам писал.
Потом молодому поколению программистов (это которые на единичку постарше нас с тобой) надоело так жить и они придумали SCTP, вебсокеты и несколько других штук где границы сообщений были, тысызыть, естественные, при сохранении общей потоковой структуры. Да что там, даже древний SSL/TLS уже общался сообщениями, надо было только через первый слой продраться и написать пакетизатор поверх голого TCP. Жалко что не до всех эти новшества дошли.
Но в общем и целом это и до сих пор большая боль, особенно если надо слать какие-либо структурированные данные. В XMPP, помню, какие-то трюки применялись для того чтобы xml слать кусками, причём именно нужными кусками. В json-rpc вообще не заморачиваются, и на каждое сообщение открывают новое соединение. Т.е. кончился жсончик, хоть их трёх байт — давай, досвидания. Следующее сообщение пойдет следующим коннектом, ну или пожалте бриться — т.е. изобретать свой фрейминг.
Другое дело что сериальному линку отсутствие фреймов _присуще_. Просто в силу нижележащей физики. А в тцп могли бы что-нибудь и придумать, учитывая количество прочих наворотов которые там есть.
А вот почему фрагментируется UDP — это загадка. Оно, по идее, должно быть прозрачно. Возможно тоже какой-нибудь эмбеддер привнёс своё понимание сути вещей.
Re: и не-эмбедщиков тоже
Date: 2021-07-24 05:54 pm (UTC)Re: и не-эмбедщиков тоже
Date: 2021-07-24 07:11 pm (UTC)Впрочем что в голове у отдельных представителей программерского племени можно только догадываться. Я еще давно в M.D. когда мы очередной движок к нашему поделию прикручивали наткнулся на.... в общем, там можно было запустить несколько задач разом, но колбэк который возвращал результаты никак задачу не идентифицировал. Я еще тогда напряг Каца чтобы он сходил до тех девелоперов и донёс до них идею добавить какой-нито пользовательский контекст и они даже сделали, но сопроводили комментарием в духе "не знаем зачем это вам, но если просите то вот".
Как бы базовая вещь, но в данном случае пришлось вот объяснять отдельно.
no subject
Date: 2021-07-24 07:03 am (UTC)no subject
Date: 2021-07-24 07:13 pm (UTC)