Ну хардкод здесь просто для упрощения понимания. Ничто не мечтает параметризовать все тайминги и счётчики. Точно так же код можно переиспользовать при обработке событий "выключение" и "отключение", вынеся в отдельные функции.
Сила SDL в том, что там сразу для каждого состояния видно, какие события при каком состоянии заставляют автомат работать и менять состояние на новое.
Код в таком случае выглядит как обычный event loop, который обрабатывает поступающие в него входящие события (команды, таймер). При получении очередного события определяется текущее состояние автомата и делегируется обслуживание сообщения соответствующей функции, отвечающей за логику обработки событий в конкретном состоянии автомата. Если говорить применительно к нарисованной картинке - то у нас будут две функции. Первая обрабатывает состояние светофора "Зелёный", вторая - "Мигающий зелёный".
Получается нужна божественная переменная (enum), которая хранит состояние автомата, то есть всей системы?
На то он и автомат, потому что finite STATE machine. Описывать автомат конкретными состояниями и диаграммой перехода между ними проще, чем иметь размазанное в нескольких переменных состояние. Ещё раз - смотрите в сторону SDL, где любая диаграмма начинается с блока, обозначающего текущее состояние.
вот мне кажется что обычно происходит путаница в том что является контекстом, а что состоянием.
Переменная состояния сама по себе может быть частью контекста. Конкретный пример FSM - OpenGL. Вы создаёте OpenGL context и вызываете последовательно функции, которые меняют его состояние. Это абсолютно аналогично тому, как в телекоммуникациях какой-нибудь прибор, обслуживающий систему, принимал некие управляющие сообщения и обрабатывал их.
я очень давно такого не видел, и забыл что так бывает!
Это видит каждый, кто ездит за рулём, и происходит это постоянно. Есть правила дорожного движения, строго регламентирующие сигналы светофора, и отталкиваться при проектировании реальной системы нужно было от них.
Интересно как это будет выглядеть на языке SDL, разработанном ITU ?
Примерно вот так будет диаграмма выглядеть для двух состояний: зелёного и мигающего зелёного.
Особенность такой диаграммы в том, что она учитывает, что светофор может в любой момент быть переведён в выключенный режим (пришёл сигнал о выключении) либо в режим, когда светофор не обслуживает перекрёсток (мигающий жёлтый). В вашем примере FSM не предусматривает переход в другое состояние по приходу какого-либо внешнего сигнала, а строго идёт по таблице, т.е. работает в режиме интерпретатора.
Потом эта диаграмма очень легко переводится на любой язык программирования.
Сама по себе описанная модель светофора и реализуемого для него FSM кривая. Такое ощущение, что автор вообще никогда не разрабатывал FSM и пытается изобрести какой-то костыльный велосипед, чтобы показать, что FSM - это плохо. А по факту разарабывает очень кривой FSM, который меняет состояние по таблице.
Признак хорошего FSM:
наличие единственной переменной (enum), хранящей информацию о текущем состоянии автомата;
наличие контекста - специальной структуры данных, содержащей достаточную информацию для работы автомата;
переход между состояниями осуществляется с помощью обработки асинхронных событий (получение сообщения, срабатывание таймера).
Язык SDL, разработанный ITU, как раз, заточен на описание конечных автоматов, на которых базируются все телекоммуникации (как минимум, прошлых поколений). Как только автор постигнет SDL, сразу поймёт, как следует описывать и писать конечные автоматы правильно.
Конкретно в данной статье мы имеем очень кривой светофор, который вообще не имеет ничего общего с реальным миром. Тут дла начала следует матчасть в виде ПДД по-хорошему подучить, прежде чем садиться за разработку светофора.
Максимально приближенному к реальности светофору достаточно обладать следующей информацией:
текущее состояние: выключен (совсем не работает), отключен (работает в режиме мигающего жёлтого, не регулирует перекрёсток), разрешающий сигнал (горит зелёный), завершение разрешающего сигнала (мигает зелёный), предупреждающий сигнал (горит жёлтый), запрещающий сигнал (горит красный), переход на разрешающий сигнал (горит красный с жёлтым), аварийный режим (когда возникла какая-то ошибка в аппаратуре и без помощи обслуживающего персонала уже не обойтись);
взводимый таймер на изменение состояния;
тайминги нахождения светофора в каждом состоянии;
счётчик переключений в контексте текущего состояния (когда надо показывать мигающие сигналы).
Вы спросите, а где же состояние лампочек? А оно не нужно, оно легко выводится из параметров "текущее состояние" и "счётчик переключений", пусть состояние лампочек в виде битовой карты хранит контроллер, который этими лампочками, по сути, и управляет.
Вопрос в целом поставлен некорректно. Linux и не обязан запускать плагины от Isotope и Waves, если они не в нативном формате, ибо yabridge - это костыль для того, чтобы поддержать то, что изначально для работы под Linux не разрабатывалось. Поэтому вопрос надо ставить по-другому: почему Isotope Ozone и плагины от Waves до сих пор не выпущены нативно под Linux?
Был у меня опыт работы с одной системой. Она в синхронном режиме обслуживала HTTP-запросы. Так вот, наступает час X. По трафику всё в норме, по CPU всё в норме, количество запросов тоже не так чтобы большое. Растёт только количество потоков в пуле jetty, но они, при этом, ничем особо не заняты. А система встаёт колом.
Логичный вопрос от руководства: "как так?" ОК, садишься, поднимаешь логи, пишешь скрипт, который интегрирует время обслуживания каждого запроса по HTTP с заданным интервалом (например, 5 минут). Строишь график и наблюдаешь, как значения на полученных временных интервалах растут по экспоненте начиная с определённого количества запросов в минуту.
А причина, как выясняется позже, вполне банальная: jetty-пул обслуживает не только внешние запросы, но и внутренние RPC-запросы, из-за чего возникает так называемый "лавинный эффект", когда внешний запрос триггерит цепочку RPC-запросов и, в итоге, эта цепочка заворачивается в кольцо.
Учитывая то, что jetty-пул потоков не бесконечный, система встаёт в ожидание освобождения потока, а все потоки в пуле при этом находятся в ожидании ответа по RPC, т.е. возникает своеобразный логический дедлок по ограниченному ресурсу - потокам.
Ошибка в проектировании и реализации? Однозначно. Но обнаружить такое с обычным мониторингом RPS невозможно.
Так что пока вы не имеете хотя бы приближённого числа в часозанятиях, есть риск вот так же наколоться.
Опять эти мифические RPS для измерения нагрузки...
5 млн RPS с обслуживанием в 10 микросекунд на запрос и те же 5 млн RPS с обслуживанием по минуте на запрос - это совершенно разная нагрузка, отличающаяся на порядки.
Нагрузку мерят либо в часозанятиях, либо в эрлангах.
Статья весьма безграмотная, примеры и аналогии притянуты за уши.
Видимо, автор сам пороха не нюхал на ассемблере под обе сравниваемые архитектуры толком и не программировал. Всё отличие RISC от CISC можно пояснить двумя отдельными пунктами:
Длина команды: у CISC она переменная, у RISC — постоянная. Это отчасти верно, но есть особенности, т.к. у тех же ARM и RISC-V есть возможность исполнять сокращённые в два раза по длине команды для увеличения плотности кода.
Наличие отдельных выделенных команд пересылки данных между памятью и регистрами в RISC, в то время как в CISC команды могут в качестве операнда использовать ячейку памяти.
То, что в RISC какой-то убогий набор инструкций — уже давно миф и результат неправильного перевода самой аббревиатуры RISC на русский язык. В современных ARM и MIPS даже SIMD есть (который, к слову, местами попродвинутее SSE и AVX будет), который сейчас является одним из ключевых способов оптимизации производительности обработки данных.
Вот тут у меня глаза вытекли. Сделать нормальное DOM-дерево? Нет, давайте запихаем списки в srcset и sizes. Отличное решение, нечего сказать. Как хочу, так и ворочу.
В самом лайвкодинге ничего плохого нет. Он ставит целью проверить соображалку разработчика и умение родить какой-то алгоритм.
Когда я проводил собеседования, то просил разработчка изобразить какой-нибудь простой алгоритм на целевом языке на доске. Сразу с оговорками, что всякие синтаксические ошибки если и будут — то не страшно. Из задач предлагалось обычно перевернуть строчку задом наперёд или поменять порядок бит в числе на обратный. Требовать парсер выражений писать бессмысленно. Так вот, далеко не все Senior'ы даже с такими задачами справлялись (что, в первую очередь, говорит о качестве рынка разработчиков в целом).
Но если к вам приходят чуваки и говорят работать строго в одной парадигме (TDD), то от них надо бежать сломя голову. И есть серьёзные сомнения, что с архитектурой их проекта тоже не всё в порядке, и там костыль на костыле, но зато тесты работают.
Извините меня за грубость, конечно, но это онанизм.
Это сроде малолеткам, которые только начали осваивать язык, и пытаются всячески выпендриться перед своими сверстниками, заявляя: "А смотрите, как Я МОГУ!"
Конечные автоматы?
Не, не слышали!
Плодим новые сущности без сильной надобности?
Ну и фиг с ним!
Код будет выполняться медленнее?
Да кого это заботит!
Отладка всего этого дела превращается в ад?
Да ты просто вот эту крутую IDE не осилил, кекеке!
Ещё один конкретный пример того, что оптимизаторы SQL-запросов в СУБД промышленного уровня всё равно тупые. Сколько я намучался в своё время с оптимизатором Oracle, который очень своевольничал, — это не перечесть.
Иными словами: если вы не понимаете структуру ваших данных, то и работа с ними будет далеко неоптимальной.
>А с Linux… Постоянно сталкиваюсь с проблемами подключения
То есть то, что производители клепают дрова для своих поделий только под Win/Mac, не учитываем, ок. В остальном же, если Wifi на поддерживаемом чипе, проблем не возникнет. Уважающие себя производители принтеров также предоставляют драйверы для Linux. Конкретный пример — HP, Kyocera.
>Плюс слабый GUI в Linux
Не знаю, какие вообще могут быть претензии по GUI к системе, которая изначально разрабатывалась как CLI. Большую часть работы можно сделать из консоли, если это только не какая-нибудь графика/мультимедиа. KDE так вообще практически не вызывает нареканий. Разве что четвёртая версия в плане оформления получше пятой была (на мой взгляд). Запустить приложения, рассовать их по рабочим столам и пользоваться — что ещё нужно? Больше свистелок и перделок? Как говорится, вам шашечки или ехать?
Кстати говоря, после продолжительного промежутка времени непользования Win появилась возможность пощупать Win 7, Win 8.1 и Win 10. Вы вообще как этим пользуетесь??? Что там удобного-то?
>А какая разница где именно проблема?
Ну, то есть, когда проблема за Windows, вы предпочитаете терпеть и молчать. А когда, как вам кажется, проблема с Linux, вы сразу почему-то начинаете про «шаманство» какое-то. Какое-то непоследовательное и необъективное у вас отношение к делу.
>Нам ж ради удобства работы, а не ради оснований для аргументации это надо.
Если не говорить по какой-то дико проприетарный софт, под Linux всё, что нужно, есть для разработки, и даже более.
>Я вот как-то не готов сидеть на системе, с которой нужно бороться, только ради того, чтобы сказать «зато у меня круто кастомизированная вещь, да, я на её настройку потратил несколько дней, зато теперь я не как все»
Не знаю, где вы там боретесь. Один раз поставил, настроил и забыл на года. А учитывая то, что сейчас куча user-friendly дистрибутивов расплодилось, вся настройка сводится к подключению нужных репозиториев с ПО, его установке и минимальной настройке.
Совсем не хотите мучаться с настройкой в консоли — ставьте openSUSE и пользуйте YaST.
Конкретные недостатки HTTP, применительно к версии 1.x:
— дикий оверхед по заголовкам и телу сообщения — неэффективное использование трафика;
— отуствие конвейеризации запросов: вы не можете по одному и тому же сокету отправить запросы 1 и 2 на сервер, а ответы получить в обратном порядке — сначала на 2, а потом на 1. Иными словами, сетевой сокет простаивает, когда мог бы заниматься полезной работой.
— На практике редко кто поддерживает персистентные соединения, отсюда имеем оверхед по времени на установление TCP-соединения (TCP handshake) и, если используется SSL, то ещё и на SSL handshake.
Да и, в принципе, всё тот же самый обмен сообщениями можно организовать напрямую через TCP-сокет, без привлечения протокола прикладного уровня, коим является HTTP.
С самого начала создания первой сети, Святым Граалем сетевых вычислений было предоставления программных интерфейсов для доступа к удалённым сетевым ресурсам таким же образом, как к локальным. Сеть становится "прозрачной".
Один пример прозрачности сети — знаменитый RPC (удалённый вызов процедур, remote procedure call), система разработанная для того, чтобы вы могли вызывать процедуры (подпрограммы), выполняющиеся на другом компьютере, по сети точно так же, как если бы они выполнялись локально. На это угробили чёртову пропасть энергии.
Звучит логично, правильно?
Неправильно.
Заключение: В следующий раз, когда кто-то попытается продать вам программный продукт, который позволяет вам обращаться к сетевым ресурсам также как к локальным, убегайте как только можете в противоположном направлении.
RPC поверх HTTP — ещё большее зло, которое, в принципе, могло придумать человечество.
Но практика показывает, что плохие вещи почему-то набирают бОльшую популярность, чем хорошие.
Ну хардкод здесь просто для упрощения понимания. Ничто не мечтает параметризовать все тайминги и счётчики. Точно так же код можно переиспользовать при обработке событий "выключение" и "отключение", вынеся в отдельные функции.
Сила SDL в том, что там сразу для каждого состояния видно, какие события при каком состоянии заставляют автомат работать и менять состояние на новое.
Код в таком случае выглядит как обычный event loop, который обрабатывает поступающие в него входящие события (команды, таймер). При получении очередного события определяется текущее состояние автомата и делегируется обслуживание сообщения соответствующей функции, отвечающей за логику обработки событий в конкретном состоянии автомата. Если говорить применительно к нарисованной картинке - то у нас будут две функции. Первая обрабатывает состояние светофора "Зелёный", вторая - "Мигающий зелёный".
Должна открываться. Попробуйте трёхбуквенные сервисы.
В диаграмме забыл "да"/"нет" ветки подписать. Думаю, разберётесь, какая "да", а какая "нет".
На то он и автомат, потому что finite STATE machine. Описывать автомат конкретными состояниями и диаграммой перехода между ними проще, чем иметь размазанное в нескольких переменных состояние. Ещё раз - смотрите в сторону SDL, где любая диаграмма начинается с блока, обозначающего текущее состояние.
Переменная состояния сама по себе может быть частью контекста. Конкретный пример FSM - OpenGL. Вы создаёте OpenGL context и вызываете последовательно функции, которые меняют его состояние. Это абсолютно аналогично тому, как в телекоммуникациях какой-нибудь прибор, обслуживающий систему, принимал некие управляющие сообщения и обрабатывал их.
Это видит каждый, кто ездит за рулём, и происходит это постоянно. Есть правила дорожного движения, строго регламентирующие сигналы светофора, и отталкиваться при проектировании реальной системы нужно было от них.
Примерно вот так будет диаграмма выглядеть для двух состояний: зелёного и мигающего зелёного.
https://ibb.co/QyjcmPM
Особенность такой диаграммы в том, что она учитывает, что светофор может в любой момент быть переведён в выключенный режим (пришёл сигнал о выключении) либо в режим, когда светофор не обслуживает перекрёсток (мигающий жёлтый). В вашем примере FSM не предусматривает переход в другое состояние по приходу какого-либо внешнего сигнала, а строго идёт по таблице, т.е. работает в режиме интерпретатора.
Потом эта диаграмма очень легко переводится на любой язык программирования.
Сама по себе описанная модель светофора и реализуемого для него FSM кривая. Такое ощущение, что автор вообще никогда не разрабатывал FSM и пытается изобрести какой-то костыльный велосипед, чтобы показать, что FSM - это плохо. А по факту разарабывает очень кривой FSM, который меняет состояние по таблице.
Признак хорошего FSM:
наличие единственной переменной (enum), хранящей информацию о текущем состоянии автомата;
наличие контекста - специальной структуры данных, содержащей достаточную информацию для работы автомата;
переход между состояниями осуществляется с помощью обработки асинхронных событий (получение сообщения, срабатывание таймера).
Язык SDL, разработанный ITU, как раз, заточен на описание конечных автоматов, на которых базируются все телекоммуникации (как минимум, прошлых поколений). Как только автор постигнет SDL, сразу поймёт, как следует описывать и писать конечные автоматы правильно.
Конкретно в данной статье мы имеем очень кривой светофор, который вообще не имеет ничего общего с реальным миром. Тут дла начала следует матчасть в виде ПДД по-хорошему подучить, прежде чем садиться за разработку светофора.
Максимально приближенному к реальности светофору достаточно обладать следующей информацией:
текущее состояние: выключен (совсем не работает), отключен (работает в режиме мигающего жёлтого, не регулирует перекрёсток), разрешающий сигнал (горит зелёный), завершение разрешающего сигнала (мигает зелёный), предупреждающий сигнал (горит жёлтый), запрещающий сигнал (горит красный), переход на разрешающий сигнал (горит красный с жёлтым), аварийный режим (когда возникла какая-то ошибка в аппаратуре и без помощи обслуживающего персонала уже не обойтись);
взводимый таймер на изменение состояния;
тайминги нахождения светофора в каждом состоянии;
счётчик переключений в контексте текущего состояния (когда надо показывать мигающие сигналы).
Вы спросите, а где же состояние лампочек? А оно не нужно, оно легко выводится из параметров "текущее состояние" и "счётчик переключений", пусть состояние лампочек в виде битовой карты хранит контроллер, который этими лампочками, по сути, и управляет.
Вопрос в целом поставлен некорректно. Linux и не обязан запускать плагины от Isotope и Waves, если они не в нативном формате, ибо yabridge - это костыль для того, чтобы поддержать то, что изначально для работы под Linux не разрабатывалось. Поэтому вопрос надо ставить по-другому: почему Isotope Ozone и плагины от Waves до сих пор не выпущены нативно под Linux?
Был у меня опыт работы с одной системой. Она в синхронном режиме обслуживала HTTP-запросы. Так вот, наступает час X. По трафику всё в норме, по CPU всё в норме, количество запросов тоже не так чтобы большое. Растёт только количество потоков в пуле jetty, но они, при этом, ничем особо не заняты. А система встаёт колом.
Логичный вопрос от руководства: "как так?" ОК, садишься, поднимаешь логи, пишешь скрипт, который интегрирует время обслуживания каждого запроса по HTTP с заданным интервалом (например, 5 минут). Строишь график и наблюдаешь, как значения на полученных временных интервалах растут по экспоненте начиная с определённого количества запросов в минуту.
А причина, как выясняется позже, вполне банальная: jetty-пул обслуживает не только внешние запросы, но и внутренние RPC-запросы, из-за чего возникает так называемый "лавинный эффект", когда внешний запрос триггерит цепочку RPC-запросов и, в итоге, эта цепочка заворачивается в кольцо.
Учитывая то, что jetty-пул потоков не бесконечный, система встаёт в ожидание освобождения потока, а все потоки в пуле при этом находятся в ожидании ответа по RPC, т.е. возникает своеобразный логический дедлок по ограниченному ресурсу - потокам.
Ошибка в проектировании и реализации? Однозначно. Но обнаружить такое с обычным мониторингом RPS невозможно.
Так что пока вы не имеете хотя бы приближённого числа в часозанятиях, есть риск вот так же наколоться.
Опять эти мифические RPS для измерения нагрузки...
5 млн RPS с обслуживанием в 10 микросекунд на запрос и те же 5 млн RPS с обслуживанием по минуте на запрос - это совершенно разная нагрузка, отличающаяся на порядки.
Нагрузку мерят либо в часозанятиях, либо в эрлангах.
Статья весьма безграмотная, примеры и аналогии притянуты за уши.
Видимо, автор сам
пороха не нюхална ассемблере под обе сравниваемые архитектуры толком и не программировал. Всё отличие RISC от CISC можно пояснить двумя отдельными пунктами:То, что в RISC какой-то убогий набор инструкций — уже давно миф и результат неправильного перевода самой аббревиатуры RISC на русский язык. В современных ARM и MIPS даже SIMD есть (который, к слову, местами попродвинутее SSE и AVX будет), который сейчас является одним из ключевых способов оптимизации производительности обработки данных.
Вот тут у меня глаза вытекли. Сделать нормальное DOM-дерево? Нет, давайте запихаем списки в srcset и sizes. Отличное решение, нечего сказать. Как хочу, так и ворочу.
Когда я проводил собеседования, то просил разработчка изобразить какой-нибудь простой алгоритм на целевом языке на доске. Сразу с оговорками, что всякие синтаксические ошибки если и будут — то не страшно. Из задач предлагалось обычно перевернуть строчку задом наперёд или поменять порядок бит в числе на обратный. Требовать парсер выражений писать бессмысленно. Так вот, далеко не все Senior'ы даже с такими задачами справлялись (что, в первую очередь, говорит о качестве рынка разработчиков в целом).
Но если к вам приходят чуваки и говорят работать строго в одной парадигме (TDD), то от них надо бежать сломя голову. И есть серьёзные сомнения, что с архитектурой их проекта тоже не всё в порядке, и там костыль на костыле, но зато тесты работают.
Извините меня за грубость, конечно, но это онанизм.
Это сроде малолеткам, которые только начали осваивать язык, и пытаются всячески выпендриться перед своими сверстниками, заявляя: "А смотрите, как Я МОГУ!"
Конечные автоматы?
Не, не слышали!
Плодим новые сущности без сильной надобности?
Ну и фиг с ним!
Код будет выполняться медленнее?
Да кого это заботит!
Отладка всего этого дела превращается в ад?
Да ты просто вот эту крутую IDE не осилил, кекеке!
Отвратительно до боли.
Ещё один конкретный пример того, что оптимизаторы SQL-запросов в СУБД промышленного уровня всё равно тупые. Сколько я намучался в своё время с оптимизатором Oracle, который очень своевольничал, — это не перечесть.
Иными словами: если вы не понимаете структуру ваших данных, то и работа с ними будет далеко неоптимальной.
То есть то, что производители клепают дрова для своих поделий только под Win/Mac, не учитываем, ок. В остальном же, если Wifi на поддерживаемом чипе, проблем не возникнет. Уважающие себя производители принтеров также предоставляют драйверы для Linux. Конкретный пример — HP, Kyocera.
>Плюс слабый GUI в Linux
Не знаю, какие вообще могут быть претензии по GUI к системе, которая изначально разрабатывалась как CLI. Большую часть работы можно сделать из консоли, если это только не какая-нибудь графика/мультимедиа. KDE так вообще практически не вызывает нареканий. Разве что четвёртая версия в плане оформления получше пятой была (на мой взгляд). Запустить приложения, рассовать их по рабочим столам и пользоваться — что ещё нужно? Больше свистелок и перделок? Как говорится, вам шашечки или ехать?
Кстати говоря, после продолжительного промежутка времени непользования Win появилась возможность пощупать Win 7, Win 8.1 и Win 10. Вы вообще как этим пользуетесь??? Что там удобного-то?
Ну, то есть, когда проблема за Windows, вы предпочитаете терпеть и молчать. А когда, как вам кажется, проблема с Linux, вы сразу почему-то начинаете про «шаманство» какое-то. Какое-то непоследовательное и необъективное у вас отношение к делу.
>Нам ж ради удобства работы, а не ради оснований для аргументации это надо.
Если не говорить по какой-то дико проприетарный софт, под Linux всё, что нужно, есть для разработки, и даже более.
>Я вот как-то не готов сидеть на системе, с которой нужно бороться, только ради того, чтобы сказать «зато у меня круто кастомизированная вещь, да, я на её настройку потратил несколько дней, зато теперь я не как все»
Не знаю, где вы там боретесь. Один раз поставил, настроил и забыл на года. А учитывая то, что сейчас куча user-friendly дистрибутивов расплодилось, вся настройка сводится к подключению нужных репозиториев с ПО, его установке и минимальной настройке.
Совсем не хотите мучаться с настройкой в консоли — ставьте openSUSE и пользуйте YaST.
Ну так вы своим комментарием, как раз, подтверждаете, что проблема в системе, которая запускает сервер GDB — то есть, Windows.
— дикий оверхед по заголовкам и телу сообщения — неэффективное использование трафика;
— отуствие конвейеризации запросов: вы не можете по одному и тому же сокету отправить запросы 1 и 2 на сервер, а ответы получить в обратном порядке — сначала на 2, а потом на 1. Иными словами, сетевой сокет простаивает, когда мог бы заниматься полезной работой.
— На практике редко кто поддерживает персистентные соединения, отсюда имеем оверхед по времени на установление TCP-соединения (TCP handshake) и, если используется SSL, то ещё и на SSL handshake.
Да и, в принципе, всё тот же самый обмен сообщениями можно организовать напрямую через TCP-сокет, без привлечения протокола прикладного уровня, коим является HTTP.
Об rpc ещё писали в незнамо каких лохматых годах.
RPC поверх HTTP — ещё большее зло, которое, в принципе, могло придумать человечество.
Но практика показывает, что плохие вещи почему-то набирают бОльшую популярность, чем хорошие.