HTTP vs FTP vs ... ???

посоветуйте самый производительный способ

http + cdn

нет, сервер будет один, а почему не фтп?

Если все устройства находятся в локальной сети (сети провайдера, например), можно использовать мультикаст как для проверки версии, так и для загрузки самих обновлений.

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

Для такого ботнета торрент подойдет.

)) а это интересно, благо буду там либо полное соответствие протоколу webrtc пилить, либо подобие, что позволит в принципе и файлами обменяться…

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

Простейший костыль: рандомизировать время проверки обновлений, чтобы устройства не ломились за ними одновременно

Тогда время приведения сети к одной версии большое

сервер будет один, а почему не фтп?

Ну всё равно http, потому что оно кэшируется.

А можешь сервер сам написать? Чтобы по очереди отдавал обновления? Ну или одновременно 10 устройствам, а остальным отдается ответ типа «очередь заполнена, попробуйте выполнить попытку через 1 час (или в такую то дату в такое то время)».

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

Если «размать» процесс обновления, скажем, на полчаса, то это сильно снизит нагрузку сервер, не создав проблем для многих практических задач. Конечно, могут быть и исключения (например, если устройства взаимодействуют с сервером и/или между собой по протоколу, у которого нет совместимости между версями) - но тогда одного сервера явно мало, и придется поработать над производительностью.

Ну хотел ты и чтобы быстро и не падало. Тогда нужно или как выше писали или самому увеличивать мощность сервера /ставить несколько серверов.

Ну всё равно http, потому что оно кэшируется.

Это актуально, только если устройства обращаются к серверу через прокси.

Пока сам нет, только коммунизжу из опенсорса )

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

Т.е. сам какой нибудь аппач не поднимает файлы в кеш?

HTTP гибче, если не лениво на самих устройствах делать обработку кодов возврата. Опять же, легко примотать к серверу любую логику, если понадобится. Например, логику проверки «устройство сообщает свою версию и сервер решает, обновлять его или не надо». Или, скажем, пока первая прибежавшая пачка устройств тащит новую версию прошивки, остальным можно отдавать 503 и пусть приходят позже.
К тому же при использовании шифрования ФТП не всегда пролезает сквозь NAT, даже одиночный.

Спасибо, про 503 это получается то что надо.

Особенно с https.

Особенно если есть возможность обработать Retry-After на клиенте, угу.

Т.е. сам какой нибудь аппач не поднимает файлы в кеш?

Для начала надо определиться, о каком кэше идет речь. Если сервер раздает клиентам файл из своей файловой системы, этот файл попадает в page cache Linux, т.е. с диска он считывается только один раз, а дальнейшая раздача идет из памяти. И тут абсолютно неважно, какой протокол использует сервер для общения с клиентами, главное, чтобы сервер не использовал для обращения к файлам Direct I/O (nginx, например, можно заставить так делать - тогда файл будет каждый раз считываться заново).

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

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

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

Кидай файлы в tmpfs и любой софт будет использовать «кэшированную» версию)

Но выше уже ответили про стандартные заголовки http «приходите позже», самый простой и стандартный вариант.

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

В юникс-подобных системах смысла в таком практически нет, разве что некоторые производители баз данных считают себя умнее ОС и велосипедят свой кэш.

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

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

rsync?

ИМХО, хорошее предложение - кэшировать средствами reverse-proxy, если планируется http. Если свой сервер для раздачи обновления - можно просто держать в памяти нужные данные, этим слегка ускорим процесс.

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

По потоколу: а gRPC не вариант? ИМХО, может быть побыстрее. Там можно и TLS и аутентификацию…

Syncthing или Resilio sync (последний - коммерческий).
п2п сеть доставки файлов, основанная на бит-торрент протоколе - каждый клиент одновременно является ретранслятором файлов.
чем больше сеть, тем меньше нагрузка на сервер, передача файлов равномерно распределяется на все устройства сети.

При всей моей любви в syncthing, ты его ресурсоемкость видел?

Тут торрент выигрывает по всем параметрам.

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

что ты подразумеваешь под ресурсоемкостью ??

$ ps aux | grep syncthing
USER   PID  %CPU %MEM   VSZ   RSS TTY STAT START   TIME COMMAND
pfg    648  0.0  0.4 732904 17656 ?   SNsl 10:44   0:00 /usr/bin/syncthing serve ...
pfg    767  0.2  1.2 804332 51000 ?   SNl  10:44   0:57 /usr/bin/syncthing serve ...

+, а еще можно tftp

Эти устройства ЭЦП проверяют при закачке?

У tftp даже аутентификации нет, фу.

А смысл аутентификации, если она не подкреплена криптографией?

Куча оверхеда относительно торрентов, RSS и даже размер бинаря.

Вкорячивал я syncthing на роутер, так проще и дешевле под него мобилку подложить, чем затюнить syncthing под <сотню MB RAM.

Чтобы аутентифицироваться. https://www.ietf.org/rfc/rfc2617.txt

Тем более фу.

Похоже на обновление STB. Обращение к серверу обновлений со случайным временным разбросом там стандартная практика.

У tftp даже аутентификации нет, фу.

Если скачиваемый файл подписан, это не важно.

Нет, это очень долго! Уже проверено

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

Периодически требуется тысячам устройств проверить актуальность своего ПО и скачать последнюю версию к себе.

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

«может что-то в консерватории поменять» :-)

например из 200Mb действительно часто обновляется килобайт эдак 100 данных (ключи,коэффициенты, адреса/настройки). Время от времени и значительно реже отдельные модули кода и баз, до 10Мб. И только пару раз за весь срок эксплуатации требуется обнова всей прошивки

как доп.лекарство - сразу получше писать/тестировать/отлаживать чтобы потом не распихивать блоб 200Мб по тыщщам устройств; Но это фантастика

PS/ для распихивания блобов по клиентам, специально сделаны всякие «облачные» сервисы. Клиент по http или всяких MQ узнаёт о новой версии, по http забирает её из облака. Как конкретно там храниться и как параллелятся запросы, тебя не должно волновать - ты за это заплатил деньги.

Кто понял жизнь - тот не спешит

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

на малинке прекрасно крутится.
на старом компухтере с вторым атлоном и 2гб памяти вообще не заметен.

У ТСа тысячи устройств и прямым текстом просьба посоветовать самый производительный способ. Если так жаждешь советовать synching не к месту, то кто ж тебя остановит, но вряд ли ты ему заодно подкинешь ещё и сотни гигов RAM и немножечко мощности CPU.

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

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

Ой, спасибо, кэп. При этом торрент точно ненапряжен для сервера обновлений, а вот сколько будет жрать каждая нода твоего многотысячного syncthing-кластера я и представить боюсь. Кто-нибудь их вообще делал такие большие?

сервер не ддосился таким обменом.

Если это просто раздача статики, то nginx пару тысяч rps выдаст

однако когда там 2к устройств начинают файлами шуршать

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

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

Периодически требуется тысячам устройств проверить актуальность своего ПО и скачать последнюю версию к себе.

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