HTTP vs FTP vs ... ???

Ох какие люди.. :)

Все правильно сказал.

Я там поудалял комментарии свои, так как посчитал коммент золдена исчерпывающим, но видимо зря. Открой удаленные, если что.

) это которые про вопрос где работаю?

еще раз - обновлять рандомно это бред

что касается STB и прочего - да это одноплатники на arm

Да что ж вы такое несёте то, господа пятизвёздочные системные администраторы и 300е наносеки, я аж залогинился. Остановитесь! Вы вообще в реальной жизни сталкивались с такими задачами?

Конечно. Мультикаст - отличная штука в тех местах, где он работает.

обновлять рандомно это бред

Это «индустриальный стандарт»

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

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

это хорошо, когда изменения в 2х мегабайтах и никакие зависимости не тянутся, вот например решил я добавить новый функционал - делаю по вашему предложению динамическую линковку этого функционала - все, теперь то ПО которое крутится ничего не знает о дополнительных 2х мегабайтах

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

кстати те 2к устройств что кладут фтп сервер вообще скачивают по 1-0.5 КБ файлы, а время случайного обновления длится рабочую НЕДЕЛЮ

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

Не нужно никаких зависмостей анализировать. Берется каталог со старой прошивкой и каталог с новой. Они сравниваются. Вариант 1: в файл обновления помещаются все изменившиесся файлы. Вариант 2: для изменившихся файлы генерируются диффы с помощью bsdiff или чего-то подобного, на устройстве они накладываются.

вот например решил я добавить новый функционал - делаю по вашему предложению динамическую линковку этого функционала - все, теперь то ПО которое крутится ничего не знает о дополнительных 2х мегабайтах

Если что-то изменилось в линковке приложения - его файл изменится и оно «будет знать». Если это плагин, подгружающийся через dlopen - ему и не надо знать, само подхватится.

кстати те 2к устройств что кладут фтп сервер вообще скачивают по 1-0.5 КБ файлы, а время случайного обновления длится рабочую НЕДЕЛЮ

Значит или сервер (edit: программа, не железка) говно, или проблема в чем-то еще. Лично я бы для начала попробовал раздавать через nginx.

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

обновляет сейчас бинарник сам себя, это просто и надежно

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

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

обновляет сейчас бинарник сам себя, это просто и надежно

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

Когда кажется, креститься надо.

на то есть веские основания, как минимум по нагрузке на канал

У нас задача - перегнать по TCP файл из N байт. Если речь не о выжимании миллисекунд для биржевых торгов, то любой протокол, работающий поверх TCP, будет примерно одинаково эффективен. Включая даже FTP - возможно, что конкретный FTP-сервер говно и не рассчитан на работу под нагрузкой.

когда у вас 1 устройство, то ms роли не играют, когда их тысячи, то они превращаются в часы

это мне хорошо известно стало, при пересжатии видео на arm-ке, когда все ms важны.

Для файла размером 200 мегабайт экономить байты на размере заголовков протокола бессмысленно. Для реально мелких файлов - с размером порядка MTU - да, разница может быть ощутима.

нет, 200МБ конечно нет, это вообще редкая операция, просто всю сеть нужно приводить в одно состояние максимально быстро.

мктт это для файлов данных, которые как раз на этих 2к устройствах.

всю сеть нужно приводить в одно состояние максимально быстро

200 Мб * 2000 устройств - это около 400 гигов.

мктт это для файлов данных, которые как раз на этих 2к устройствах.

Если данные нужно обновлять оперативно и по инициативе сервера - хороший вариант.

400 гигов при скорости канала в 100 мбит на сервере это если я правильно посчитал 8+ часов, сейчас же 100МБ на 500 устройствах обновляются рандомно 5 суток.

2к устройства еще проще, там само устройство это gsm модем с мелкими файлами и вот так действуют на фтп сервер при их обновлении.

400 гигов при скорости канала в 100 мбит на сервере это если я правильно посчитал 8+ часов

Да, поэтому их надо равномерно распределить во времени, хотя бы на полдня.

сейчас же 100МБ на 500 устройствах обновляются рандомно 5 суток.

Дичь какая-то

нет пол дня, надо за ночь ) 503 в http меня вполне устраивает, это мне позволит на максимум загрузить канал

503 в http меня вполне устраивает, это мне позволит на максимум загрузить канал

Остается только разработать логику, отвечающую за выдачу этого 503

ну я так понимаю нужно найти предельное количество на скачивание файла, остальным отдавать 503, надеюсь каким то php обойдется, а лучше настройкой самого http сервера, т.к. пилить еще что то в духе FastCGI на C/C++ не охото еще раз ))

HTTP. По нему запрашивается маленький файл с описанием последней выложенной версии. Если надо, то также по HTTP качается само обновление. Можно еще в запрос добавить текущую версию у пользвоателя для статистики. Рандомизация запросов - очень полезная штука. Можно длавить описание как рандомизировать и чеещз сколько времени делать новый запрос в первый текстовый файл

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

Я могу сванговать что FTP сервер ОП форкает по процессу на юзера, потому что это stateful протокол и права доступа там прибиты к юзерам в системе. Так что не удивительно, что он умирает.

нет, все устройства в интернетах без белых ip, файл ПО около 200Мб

А на устройствах и сервере – линукс?

Я могу сванговать что FTP сервер ОП форкает по процессу на юзера, потому что это stateful протокол и права доступа там прибиты к юзерам в системе. Так что не удивительно, что он умирает.

Recent evidence shows that vsftpd is also extremely fast and scalable. vsftpd has achieved ~4000 concurrent users on a single machine, in a production environment.

https://github.com/InfrastructureServices/vsftpd

Причем, если я правильно понял, vsftpd форка по одному или два (в зависимости от настроек) процесса на каждую сессию. Вред форков сильно преувеличен фанатами c10k.

Рандомизировать время проверки. Чтобы устройства не одновременно обращались, а в течении дня. Несколько тысяч запросов хотя бы за час, а не за одну секунду - ничего не завалит. А по протоколу я бы использовал HTTP, так как это будет проще в реализации для RO доступа. Плюс FTP вообще умирает уже.

Даже если рандомизировать в рамках одной минуты это уже снизит нагрузку в 60 раз на сервер. Мне кажется, очень мало задач, где лаг обновления в 1 минуту будет на что-то влиять. Тем более что такой же лаг может быть просто от разницы скорости загрузки файла разными устройствами из-за топологии сети и вселенского рандома.

да, на устройствах убунта, на сервере дебиан

А зачем нужен FTP для Read-only распространения данных? FTP тупо тяжелее как протокол (и не удивительно, что он у тебя ложится от 1000 одновременных закачек, какой-нибудь nginx скорее всего легко раздал бы статику с такой нагрузкой). Единственное его преимущество это встроенная поддержка аплоада файлов (а для HTTP нужны дополнительные слои абстракции типа WebDav), но ты ведь обновления на железки раскатываешь, а не совместный RW доступ к файлам юзерам обеспечиваешь.

а для HTTP нужны дополнительные слои абстракции типа WebDav

nginx поддерживает заливку файлов PUT-запросами

2к железок помимо чтения еще и пишут такие же мелкие файлы, типа лога загрузки, всю мелочь планирую на mqtt перенести, кинул файл 200KB через него - все пришло, хз сколько максимум кинуть можно )

Тут выше только что подсказали, что nginx умеет закачку файлов. При таком раскладе FTP вообще теряет смысл.

А DELETE можно, чтобы два раза не вставать?

Обновлять рандомно можно раз в сутки, а можно рандомизировать +-1 минуту. Это уменьшит нагрузку на сервер в 60 раз, хотя лаг появления обновлений будет всего лишь в 1 минуту. Тут вопрос тюнинга рандомизации обновления под задачу.

время случайного обновления длится рабочую НЕДЕЛЮ

Так кто тебя заставляет делать рандомизацию прям в течении недели. Делай в течении суток или даже часов/минут. Попробуй разные параметры рандомизации.

кстати те 2к устройств что кладут фтп сервер вообще скачивают по 1-0.5 КБ файлы

Потому что тут главная проблема в самом FTP, который в 2023 году немного так устарел. Nginx с HTTP справился бы с 2000 запросов даже в одну секунду, если речь о раздаче простой статики. Ты просто используешь устаревший неподходящий для задачи инструмент.

FTP был популярен во времена, когда, во-первых, у сайтов пользователей было мало, а во-вторых, HTTP сервера мало умели.

Для веба лучше подходят всякие питоны и ноды, так как там есть готовые фреймворки и либы для написания HTTP серверов. На раздаче статики по простым правилам ты никак не сможешь раскрыть потенциал C/C++ кода, ибо задача целиком и полностью I/O bound. У PHP будет проблема с хранением глобального стейта, так как каждый скрипт имеет независимый контекст, разве что БД прикручивать. А на python/nodejs можно будет ограничиться счётчиком загрузок в глобальной переменной.

А DELETE можно, чтобы два раза не вставать?

https://nginx.org/ru/docs/http/ngx_http_dav_module.html

Потому что тут главная проблема в самом FTP, который в 2023 году немного так устарел. Nginx с HTTP справился бы с 2000 запросов даже в одну секунду, если речь о раздаче простой статики.

См. мой комментарий выше, vsftpd утверждает, что вывозит 4к одновременных загрузок в продакшене.

Rsync предлагали?

При таком раскладе FTP вообще теряет смысл.

Во-первых, кто-то должен разграничение прав на файлы. В узкоспециализированных сценариях можно считать всех (авторизованных) клиентов доверенными, но если есть и удаление файлов, то этого уже не достаточно. Во-вторых, FTP умеет делать листинг каталогов, а у HTTP стандартного способа это делать нет.

Здорово.

Но nginx вроде как способен на 1-2 порядка больше: https://openbenchmarking.org/test/pts/nginx

С учётом того, что у ТС не самое лучшее железо по его признаниям и FTP ложится, то переход на HTTP с nginx может быть способом кратно поднять производительность.

Подавляющее большинство веб-серверов имеют встроенную опцию листинга каталогов, которая либо активна из коробки, либо включается 1 переключателем в конфиге. Не стандартизировано, конечно, да. Хотя есть WebDav.

Если пользователей не очень много, то можно просто налепить HTTP-авторизацию прямо в конфиге nginx. Типа каждому юзеру выделить по каталогу, куда можно писать, а также общий каталог, откуда можно только читать.

Конечно, если речь идёт прям о сложной системе с кучей пользователей и каталогов, то конфиг быстро превратиться в лапшу. Тут уже будут нужны другие решения. Но у ТС вроде случай не такой, ему скорее всего даже 1 юзер на всех подойдёт.

сервер не справляющийся заставляет, еще раз повторю - радомайз это лютый бред

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

Как конкретно там храниться и как параллелятся запросы, тебя не должно волновать - ты за это заплатил деньги.

А в определённый момент они говорят что твоя страна (чисто гипотетически пример) рожей не вышла и они больше с тобой не работают.

У вас там 100 мбит? Тогда 8 часов это слишком оптимистично. Я бы сказал, 12.