Чем заменить HTTP клиента?

Как бы Вы поступили???

Оставил как есть.

как есть не устраивает, надо лучше )

А, если посчитать финансовую составляющую и сравнить поддержку в текущем состоянии и выпиливание?

поддержка текущего тоже не дешева, выпиливание конечно дороже, но зато после будет поддержка полагаю дешевле.

да забыл добавить HTTP функционал на серверах конечно же написан на PHP, а будет заменен на C/С++

может стать узким местом в алгоритме из-за однопоточности обработки очереди сообщений из mqtt

А с хттп этот вопрос как решен?

через использование nginx на одном и apache на другом сервере

Погоди, на каждой железке по два хттп-сервера? И сколько потоков (соединений) бывает к каждой железке в пике? ЯННП, дай подробностей.

на каждой железке условные 2 хттп клиента, туда через сип или мктт что то шлешь, а они ответы в хттп заворачивают, а шлют их в зависимости от логики на один из двух физических хттп серверов.

функционал на HTTP

Что это за функциональность?

непреодолимое желание выпилить

Чем оно обусловлено?

Что это за функциональность?

например, полазила в БД или отправила push на андройд и тд.

Чем оно обусловлено?

упрощение и увеличение надежности работы самих железок, а так же появится простая возможность обернуть железки в простое api

полазила в БД или отправила push на андройд

HTTP здесь причем вообще?

упрощение и увеличение надежности работы самих железок

Новых только если. ИМХО, все эти нововведения на старом парке в 1000 железяк приведут к гемморою и получению в конце по башке за простои.

появится простая возможность обернуть железки в простое api

Ну вот это, конечно, круто, но сильно зависит от того, как они выходят в сеть.

так нет клиента для БД, поэтому через ХТТП, ну пуш и того понятней почему

так не сразу на всем конечно, поэтапно и через предварительный тест, вопрос просто в том, в каком направлении сейчас пойти.

в сеть вообще как годно выходить могут, тут нет никакого ограничения.

нет клиента для БД, поэтому через ХТТП, ну пуш и того понятней почему

Звучит как три полностью несвязанных между собой технологии, имеющих друг к другу посредственное отношение, но объединенные почему-то в одну мысль.

Ты хотя бы понимаешь, что делать хочешь, как оно работает, и что ты хочешь получить в итоге?

в сеть вообще как годно выходить могут, тут нет никакого ограничения.

Как сейчас это реализовано?

понимаю, не понимаю поедет ли это колесо под серьезной нагрузкой )

ну подключают шнурок или свисток к железке и все - она в ентернетах.

ну подключают шнурок или свисток к железке и все - она в ентернетах.

Да. Только доступа к API не будет, если ты его там сделаешь.

почему, через мктт и частично сип будет.

Твое описание задачи и нюансов работы системы заставляет очень сильно сомневаться в том, что ты вообще знаешь, что делаешь. Серьезно.

Поэтому совет тут может быть один: Чем заменить HTTP клиента? (комментарий).

Если ты все равно хочешь что-то менять: флаг тебе в руки, штош. Только перед этим советую более глубоко понять, что ты хочешь делать, и как это должно работать.

То есть, ты сейчас по mqtt на управляющее событие мгновенно отвечаешь «ага», а потом неторопливо что-то выполняешь и докладываешь об этом вебсерверу, так?

) ну подожду других советов, как уже сказал этот не подходит.

да, уже приблизительно половину сделал, полагаю знаю, про что не знаю вот спросил.

верно, но без ответа ага - т.е. после события, только неторопливо хз какому (потому что пока не полностью в логике разобрался) вебсерверу

Выходит, тебе надо логику на обоих концах mqtt править. Я в целом просто так потрындеть зашел, в рамках мозгового штурма, а вообще хз, есть ли подходящие многопоточные серверы mqtt для твоих железок. Ты узнавал?

пуляй все в кафку, там и адаптеры на все протоколы есть и стейт можно откатить и вообще модно сейчас так

) спасибо, а можно по рюсски? что за кафка?

на стороне железки могу уже любую логику запилить в мктт, в сип ограниченно, на стороне серверов пока вот в раздумьях

не узнавал, из мыслей только использовать несколько обработчиков… хотя опять же какой в этом смысл если сам мктт однопоточный вроде как, если только попытаться несколько брокеров использовать.

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

спасибо еще раз, буду читать.

сам мктт однопоточный

Я не разбираюсь, но кмк тут ты чот не то говоришь. Там есть механизмы распедаливания нескольких клиентов.
Веб-серверам однопоток не мешает держать несколько подключений же.

хз, не вижу в mosquitto больше одного потока, да и другие пишут что он однопоточен

Почему тебя это волнует? Один поток не умеет много клиентов?

Ни черта не понятно из описания. Что за железки, что за серверы, что за «функционалы».

Задавая вопрос нужно сбросить все свои кеши и сформулировать проблему от и до, с уважением к контексту, которого у аудитории нет. А затем, сформулировав вопрос, ответ с большой вероятностью сам спустится в твою голову прямиком от боженьки.

Похоже что нет иба кто то через аппач на вдс сервере с меньшей производительностью уже успешно ддосил железный мктт сервер.

А может тогда ддосили именно хттп сервер, а на мктт подумал уже как общее следствие тормозов, а не то что он не вывозил ))

Вопщим надо архитектуру переделать

Есть RPC фреймворки поверх MQTT, например Apache Thrift.

MQTT это трансляция и приём телеметрии, оповещение о состоянии. Многоадресная раздача. На край - некоторые групповые команды «всем выйти из тени». В таком режиме оно великолепно работает, масштабируется и внятно управляется/администрируется. Перерос москита - взял сервер посерьёъзней, их несколько больше 1-го варианта..

Передача команд одному конкретному клиенту MQTT да ещё и с подтверждением в обратку - дикая самопальная дичь. Вот оно ломает архитектуру и возникают существенные вопросы про безопасность.

Под http насколько я понял, ТС подразумевает Rest-клиента, который обращается к его Rest-сервисам. Менять и выпиливать это совершенно точно ненадо.

А вот отправлять Push уведомления на Android, ни одна из тысяч «мелких железок» физически не должна. Вот это вот дело серверов, их мало, их можно контроллировать. Иначе мелко-железко замкнёт и она начнёт слать куда не попадя, а тебе разбираться кто из тысяч такое делает

) я через него снимки шлю и все нормально доходит иба у него ограничение 256Мб на одно сообщение, так что оповещение о состоянии это очень узкое использование.

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

но в любом случае выпилить надо, потому что проблемы решение с хттп продемонстрировало даже в плане диагностики

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