HTTP vs FTP vs ... ???

если число клиентов заранее известно - запланируй

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

присвой всем клиентам уникальные id

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

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

не http или ftp, а https/ftps/sftp, если https - то можно и самоподписанным сертификатом, главное чтобы клиенты доверяли CA

не http или ftp, а https/ftps/sftp, если https - то можно и самоподписанным сертификатом, главное чтобы клиенты доверяли CA

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

ну и раз уж мы говорим про один сервер на 2000 клиентов и обновления по 200 мб, то научи клиенты в а) докачку б) ретраи

радомайз это лютый бред

Ты вот весь тред это пишешь: а в реальной жизни все тока так и делают, наверное ж неспроста

Поясни почему бред

так уж сколько раз объяснил - ЭТО ОЧЕНЬ ДОЛГО, намного дольше чем каждый произвольно будет проверять не освободилась ли очередь, если нет - ждем условные 10 секунд и снова проверяем что там с очередью.

Но nginx вроде как способен на 1-2 порядка больше

Из чего абсолютно не следует, что на 4к соединений их производительность будет значимо отличаться. Да, у форков есть свой предел, не просто так возникла вся эта тема с c10k.

ftps/sftp

Говно/говно.

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

Максимальное количество клиентов можно задать в конфиге и у nginx, и у apache, и у vsftpd, и, наверное, у любого адекватного сервера.

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

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

Не клиентов, а закачек надо ограничить

Не клиентов, а закачек надо ограничить

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

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

Тогда надо как-то через limit_conn настраивать для локейшена с прошивками (если nginx юзать).

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

Ну прежде всего естественно забудь про FTP. А для HTTP в принципе довольно сложно сделать сервер который будучи запущенным хоть на утюге, не держал бы несколько десятков тысяч RPS быстрых запросов (т.е. без отдачи данных, это про проверку актуальности). Проверку можно в принципе и через DNS делать, это ещё быстрее и вдобавок кэшируется. А с раздачей больших прошивок интереснее.

Всё самое интересное в любом случае делается на клиентах:

• Время проверки обновлений нужно размазать как можно более равномерно - например, брать хэш от серийного номера устройства, и смещать проверку внутри заданного интервала соответственно. Так, если размазать 100k устройств равномерно с проверкой раз в сутки, то получим чуть более 1RPS равномерной нагрузки на сервер.
• Правильно обрабатывать 429 от сервера (а также серверные ошибки, чтобы если сервер упал не валить его ещё больше ретраями).
• Желательно явно работать с резолвингом DNS, чтобы несколькими A/AAAA записями можно было предсказуемо контролировать масштабирование и резервирование (это не работает предсказуемо из коробки).
• В особо тяжёлых случаях использовать торренты и/или мультикаст раздачу в локальной сети.

файл ПО около 200Мб

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

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

В более продвинутом варианте - статическое ограничение на к-во соединений и трафик + правильная обработка 429 на клиентах. Можно включать ретраи.

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

429

503.

Нжынсом можно сделать, но он не умеет лепить дополнительные заголовки к 503, поэтому интервалом гибко рулить не выйдет. Разве что ответ парсить.

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

Я знаю, что моему аккаунту после этого конец, но

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

Забанься, дебил (с). Ты со своими клиентами никогда не дойдешь до ситуации когда nginx станет узким местом.

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

Это отлично. Думал, как ответить в рамках правил лора, но не смог, поэтому просто пожелаю тебе успехов в работе.

Проверку можно в принципе и через DNS делать, это ещё быстрее и вдобавок кэшируется.

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

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

еще раз тебе повторяю - канал 100мбит, нет никаких гигабитов, 2х или 200 серверов.

а так может в отдельных случаях и 30мбит канал быть, иба для юрлиц тарифы дорогие.

теоретик интернетный.

так уж сколько раз объяснил - ЭТО ОЧЕНЬ ДОЛГО

почему долго-то? на пару минут увеличиваешь время обновления – в 120 раз снижаешь нагрузку на сервер. Мало в 120 раз? ну увеличь на 10 минут – будет в 600. Тебе 10 минут на обновление критично?

Если ты организуешь разделение по времени доступа на сервер через очередь с отлупами – то быстрее оно от этого не станет, а хлопотнее – да.

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

а вот и нет. Разделение по времени – оно и в африке разделение по времени.

У нас сделано так: коробки в статусах докладывают текущую версию прошивки и сервер сам рулит обновлением: присылает команды обновиться пачками, сначала первой группе, потом второй – и тд. И в коробках на обработки команды обновления стоит sleep( random(120) ) что позволило в сотни раз увеличить размер групп

А вообще я давно пропагандирую внедрить для этой задачи что-то торрентоподобное – само ж напрашивается. Но еще не пробовали

почему долго-то?

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

Если ты организуешь разделение по времени доступа на сервер через очередь с отлупами – то быстрее оно от этого не станет

почему это? всю жизь проверка состояния была быстрее паузы по времени.

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

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

и это не говоря о том, что на каких то устройствах 10мбит канал, на других 5мбит, на третьих 3мбит, а не которые вообще работают через gsm на скорости 200кбит, потому что покрытие в том месте гавно

предполагается что сервер одновременно может обслуживать несколько соединений, но не все разом: таким образом, вставляя перед выполнением команды обновления паузу равную рандом(60)*1сек мы снижаем количество обращений в первую секунду в 60 раз. и нагрузка на сервер плюс-минус равномерно размажется на одну минуту. если мало – поставь две, три – сколько надо. У тебя сервер не вывозит нагрузку одновременности – вот это решение по управляемому растягиванию нагрузки по времени. Решение в одну строчку кода, оно работает, повторюсь – все так и делают. Речь не о паузах в десятки часов рандомных. А просто об управляемом равномерном размазывании.

Ваше решение с контролем количества соединений, отлупом по 503 и прихождением потом – тоже рабочее. Только это то же самое, просто кода больше одной строчки и управлять этим сложнее.

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

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

ну и чем тогда это отличается от проверки доступности? плюс канал начинает ПУСТЕТЬ, а не даете второй группе начать занимать его

нет, это совершенно не то же самое, ваши радномы в 1 минуту умножьте на тысячи устройств - так и получите часы, потраченные на паузы

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

И что? Ты не упираешься в nginx никак на своём канале.

нет, это совершенно не то же самое, ваши радномы в 1 минуту умножьте на тысячи устройств - так и получите часы, потраченные на паузы

Все-таки ты и вправду не понял. Смотри, допустим, все твои устройства получают команду на обновление одновременно и каждое из них, независимо от других, выжидает рандомное время в пределах N секунд и после этого лезет обновляться. Таким образом общее время обновления любого количества устройств увеличивается на N секунд, хоть у тебя тыщя коробок, хоть – миллион. А сервер получает на N секунд времени больше на ту же работу – таким образом снижается нагрузка на сервер в пересчете на единицу времени. И она регулируется – тебе остается только найти минимально-рабочее N, чтоб сервер вывозил. Смекнул теперь?

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

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

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

едрить. У тебя сервер может одновременно две загрузки держать? А три? А сколько максимально – измерял?

Максимально быстро обновить в твоем случае сводится к максимально быстро раздать не роняя сервер. А это и означает – снизить нагрузку на сервер до максимально допустимой.

никакой N секунд никогда не будет означать одну и ту же нагрузку, это тупиковая идея даже при масштабировании.

то-то все так и делают, и впрямь – тупиковая.

Ладно, делай как знаешь: ты спрашивал совета, мы – дали. Те, собссна, все хором одно и то же сказали: влеби нджинкс, налаженный на статику – уже 80% твоей проблемы решит, плюсом – размажь по времени – это вообще все проблемы решит с запасом. Сам же сказал что не хочешь изобретать, если есть готовое – так вот, оно есть.

то-то все так и делают

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

я бы не стал некоторых называть «всеми»

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

другие с очередью дали совсем другой совет

Совсем тот же самый: странно что ты в упор этого не видишь, ну да бог с ним – 10 раз уже по кругу обсудили.

вопрос с «торрентами» пока слишком сложен в реализации.

вот это – совсем другой подход )

)) значит у вас просто ограниченный кругозор

странно что ты в упор этого не видишь

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

Для DNS время жизни записи контролируется. Есть инфа что гугл это не соблюдает, маня-теоретик?

значит у вас просто ограниченный кругозор

очень приятно было такое прочитать, после того как попытался помочь человеку (в ответ на его просьбу) в решении задачи, которую сам недавно решал. Так держать!

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

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

делаю вывод - вы просто не разбираетесь.

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

Для DNS время жизни записи контролируется

Да, но кеширующие днс твоего провайдера, например, могут класть на это.

Есть инфа что гугл это не соблюдает, маня-теоретик?

Ну есть, и что?

Да, но кеширующие днс твоего провайдера, например, могут класть на это.

Тогда они сломают всё что завязано на короткое время жизни записи типа всяких там DNS балансировок, файловеров, dnsbl и всего остального. И в DNS, вообще говоря, нет ничего уникального в плане возможности сломать - в каких-то организациях и HTTP может быть только через MITM проксю (ломающую проверку сертификатов) пускающую только определённый тип трафика (ломающую проверки обновлений и скачивание прошивок). Собственно только опу известно в каких средах будут работать его устройства, поэтому моё дело предложить вариант. А вот твоё - думать перед тем как писать категоричную чушь.

Ну есть, и что?

Показывай, что.

еще раз вам повторяю - НЕ ВСЕ посоветовали одно и то же.

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

ещё вариант, а-ля «TV по заказу» - раздавать блоб 200Mb кусками по N Mb, но зато сразу всем и можно гнать через websocket или pub/sub и серверов можно поставить много..

образно, как только появился хоть 1 подписчик: в 00:00 начинается трансляция 1-го куска, 00:10 второго и так далее по кругу..отчасти можно и вперемешку

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

http3 же

Я бы заказал CDN. 1 ТБ в селектеле 600 рублей стоит. Зато 100% все всегда получат обновления и очень быстро.

Мне кажется, для начала бы и объектного хроанилища хватило. Там тоже должны быть гарантии доступности (пусть и не настолько строгие), и канал поширше, чем 100 мбит.

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