Я вам в первом же ответе написал про аналогию с СКВ, после чего вы все равно спрашиваете о том, что новый клиент не получит старой информации или потеряет часть информации. Если вы пользуетесь гитом, то должны знать как такие проблемы решаются в гите - зачем тогда вообще задавать такие вопросы?
Проблема "точки" в том, что это уязвимость. С точки зрения ИБ. Только и всего.
Без конкретики - это просто пустые слова. Только и всего.
Даже по законам РФ это персоналка.
Нет, даже по ссылке, которую вы дали - написано:
адрес электронной почты будут являться персональными данными, если они зарегистрированы на определенное физическое лицо, что позволит идентифицировать конкретного человека.
Когда вы регистрируете (создаете) email в большинстве бесплатных почтовиков - от вас не требуют идентификации физического лица. Следовательно такой ящик может использоваться кем угодно, любым физлицом, юрлицом, группой людей, организацией, программой или даже животным и его адрес не является персональными данными.
Просто используйте email не привязанный юридически напрямую к вам и у вас никаких проблем с анонимностью не будет.
Вы можете описать в чем именно вы видите проблему такой "точки входа" ?
хранение моего почтового адреса - еще большее нарушение анонимности
Как именно нарушается ваша анонимность если бот знает ваш email? У вас единственный emal на все случаи жизни, который вам выдали после предъявления паспортных данных?
Новый клиент, допустим - уже старой информации не получит? А если часть информации клиент потеряет?
Вы точно не работали с СКВ. По аналогии с копированием репозитория, новый клиент всегда сможет запросить полную копию каталога. Будет ли он запрашивать её у главного бота или у других клиентов, получит всю сразу или по частям - это уже детали реализации, про которые пока рано говорить.
С хранением части информации на отдельном клиенте — тоже проблема.
Вы не поняли сути идеи. Вы когда нибудь работали с системой контроля версий? На клиенте хранится ВСЯ копия каталога файлов (репозитория), по почте вы получаете только обновления для модификации папки с файлами до текущей версии.
Адреса ящиков клиентов знает только бот - их спамить не получится. Спамить можно только ящики сообщества, которые работают на прием сообщений для бота. Для этих ящиков будут использоваться почтовики, которые умеют эффективно распознавать и блокировать рассылку спама, тот же Gmail например.
Это точно не Bittorrent - тут присутствует централизация в виде бота.
Тут не требуется постоянное соединение с сетью. Как для бота так и для клиента достаточно периодического сеансового соединения для приема/отправки почты.
Прием и запись обновлений на флешку производит специальная программа, она контролирует версии обновлений и все остальное связанное с целостью и объемом данных - ФС точно не пострадает.
Блокчейн используется только один раз для того чтобы опубликовать ЭЦП сообщества, чтобы никто не мог в последствии присылать обновления от имени "поддельного" сообщества. Для этого можно использовать например публикацию надписи в блокчейне BTC или текста в блокчейне ETH.
Это описание Pull-модели, и она не очень подходит для real-time взаимодействия. Вам надо будет опрашивать бд однотипными запросами. А это чтение с диска. И чем больше вы захотите приблизиться к real-time, тем больше придется дидосить бд.
Никаких лишних запросов к БД не происходит.
Вынимающий процесс - вынимает записи из БД пачками в цикле, пока не опустошит очередь и делает только те запросы, которые нужны для этого, никаких лишних запросов. Если очередь опустела и больше нечего вынимать - он засыпает.
Заполняющий процесс пишет в очередь тогда, когда сам не спит и как только он туда что-то записал - он пинает сигналом SIGCONT и пробуждает вынимающий процесс, который в этот момент либо спит и тогда просыпается и начинает выполнять свою работу либо уже работает и игнорирует SIGCONT.
Я об этом написал в статье - возможно вы её невнимательно прочли или неправильно поняли. Спящий процесс не потребляет ресурсов, а отправка межпроцессного SIGCONT - очень дешевая операция.
Таким образом, если бот простаивает - происходит следующее: работает только Input и только тогда когда запускает очередной цикл лонг полинга. Пока Телеграм не отдал ему ни одного входящего сообщения он тоже спит до таймаута лонг полинга. Все остальные процессы тоже спят и ничего не потребляют.
Как только Input хоть что-то получит от Телеграма - он записывает это в очередь обработки и пинает Proc. Тот в свою очередь, как только что-то запишет в очередь отправки - пинает Output. Всё настолько просто, что даже можно сказать - примитивно, и поэтому - быстро, надежно и безотказно работает!
Потому, что данном случае это избыточно. Зачем простую систему усложнять дополнительными сущностями и слоями взаимодействия?
Брокеры сообщений уместны: а) в распределенных системах, б) для обслуживания очередей обмена сообщениями между несколькими компонентами системы.
Тут не нужен сетевой уровень обмена, все процессы находятся в памяти одного севера и каждая очередь используется даже не для обмена, а для простой передачи сообщений от одного процесса к другому, т.е. между всего двумя процессами.
И придумывать тут особо ничего не надо, по сути любая таблица в БД с автоинкрементным ID или полем даты добавления записи - это уже очередь, в конец которой один процесс может добавлять, а другой - вынимать сообщения из начала.
Требования я сам себе ставил: простота, надежность, расширяемость, масштабируемость.
Из лучших практик - это разделение бота на отдельные, параллельно работающие сервисы, взаимодействующие между собой через обработку очередей сообщений.
Вдохновлялся я пожалуй - устройством и работой пулемета Maxim :)
Я полагал, что описываемая архитектура бота настолько проста, что достаточно текста, да и художник из меня - не очень, но раз надо графику, то вот что у меня получилось:
На 10000 семей каждый раз количество мальчиков и девочек получается примерно одинаково — по 10000 соответственно. При этом иногда получаются семьи, где есть и по 16 девочек, вот например в таком результате: Array
(
[0] => 5038
[1] => 2393
[2] => 1291
[3] => 640
[4] => 323
[5] => 169
[6] => 73
[7] => 39
[8] => 23
[9] => 5
[10] => 5
[16] => 1
)
d=10038
m=10000
ну если не думать то f = (f + 1) /2 отсюда на 1 мальчика будет 1 девочка. И ничего не меняется. Ну что логично в целом, так как количество детей никак не влияет на проценты рождаемости.
Вы забываете о том, что по условию задачи они рожают девочек пока не родится мальчик. Т.е. на первом же мальчике процесс останавливается, а девочек может быть сколько угодно до этого. Очевидно, что в этой ситуации девочек будет рождаться больше чем мальчиков, вопрос в том — насколько?
Допустим Вы решили создать бизнес сводящий таксистов и клиентов.
Да даже если и не бизнес, а просто бесплатно помочь людям в неудобных/неинтересных местах для крупного бизнеса типа Донбасса, большинства островов и т.д. наладить хоть как-то сервис перевозок. Мой знакомый уже пару лет пилит бесплатный и все равно никому особо не нужный сервис на ботах «UNTER TAXI» и тоже жалуется на проблему «замкнутого круга».
Что конкретно вам непонятно в рекомендации:
?
Вас кто-то заставляет пользоваться почтовиками, которые требуют ФИО, геолокацию и т.п. для регистрации и работы?
Я вам в первом же ответе написал про аналогию с СКВ, после чего вы все равно спрашиваете о том, что новый клиент не получит старой информации или потеряет часть информации. Если вы пользуетесь гитом, то должны знать как такие проблемы решаются в гите - зачем тогда вообще задавать такие вопросы?
Без конкретики - это просто пустые слова. Только и всего.
Нет, даже по ссылке, которую вы дали - написано:
Когда вы регистрируете (создаете) email в большинстве бесплатных почтовиков - от вас не требуют идентификации физического лица. Следовательно такой ящик может использоваться кем угодно, любым физлицом, юрлицом, группой людей, организацией, программой или даже животным и его адрес не является персональными данными.
Просто используйте email не привязанный юридически напрямую к вам и у вас никаких проблем с анонимностью не будет.
Вы можете описать в чем именно вы видите проблему такой "точки входа" ?
Как именно нарушается ваша анонимность если бот знает ваш email? У вас единственный emal на все случаи жизни, который вам выдали после предъявления паспортных данных?
Вы точно не работали с СКВ. По аналогии с копированием репозитория, новый клиент всегда сможет запросить полную копию каталога. Будет ли он запрашивать её у главного бота или у других клиентов, получит всю сразу или по частям - это уже детали реализации, про которые пока рано говорить.
Нет никакой точки входа, у вас нет адреса сервера, в ваш почтовый ящик письмо с обновлением может прийти откуда угодно.
Вы не поняли сути идеи. Вы когда нибудь работали с системой контроля версий? На клиенте хранится ВСЯ копия каталога файлов (репозитория), по почте вы получаете только обновления для модификации папки с файлами до текущей версии.
Адреса ящиков клиентов знает только бот - их спамить не получится. Спамить можно только ящики сообщества, которые работают на прием сообщений для бота. Для этих ящиков будут использоваться почтовики, которые умеют эффективно распознавать и блокировать рассылку спама, тот же Gmail например.
ARPANET - оборонный проект, а Интернет и Web, построенные на его основе - уже нет.
Это точно не Bittorrent - тут присутствует централизация в виде бота.
Тут не требуется постоянное соединение с сетью. Как для бота так и для клиента достаточно периодического сеансового соединения для приема/отправки почты.
Прием и запись обновлений на флешку производит специальная программа, она контролирует версии обновлений и все остальное связанное с целостью и объемом данных - ФС точно не пострадает.
Блокчейн используется только один раз для того чтобы опубликовать ЭЦП сообщества, чтобы никто не мог в последствии присылать обновления от имени "поддельного" сообщества. Для этого можно использовать например публикацию надписи в блокчейне BTC или текста в блокчейне ETH.
Я не нашел на этой странице информации об этом ограничении.
Посчитали, что оно не работает?
Никаких лишних запросов к БД не происходит.
Вынимающий процесс - вынимает записи из БД пачками в цикле, пока не опустошит очередь и делает только те запросы, которые нужны для этого, никаких лишних запросов. Если очередь опустела и больше нечего вынимать - он засыпает.
Заполняющий процесс пишет в очередь тогда, когда сам не спит и как только он туда что-то записал - он пинает сигналом SIGCONT и пробуждает вынимающий процесс, который в этот момент либо спит и тогда просыпается и начинает выполнять свою работу либо уже работает и игнорирует SIGCONT.
Я об этом написал в статье - возможно вы её невнимательно прочли или неправильно поняли. Спящий процесс не потребляет ресурсов, а отправка межпроцессного SIGCONT - очень дешевая операция.
Таким образом, если бот простаивает - происходит следующее: работает только Input и только тогда когда запускает очередной цикл лонг полинга. Пока Телеграм не отдал ему ни одного входящего сообщения он тоже спит до таймаута лонг полинга. Все остальные процессы тоже спят и ничего не потребляют.
Как только Input хоть что-то получит от Телеграма - он записывает это в очередь обработки и пинает Proc. Тот в свою очередь, как только что-то запишет в очередь отправки - пинает Output. Всё настолько просто, что даже можно сказать - примитивно, и поэтому - быстро, надежно и безотказно работает!
Потому, что данном случае это избыточно. Зачем простую систему усложнять дополнительными сущностями и слоями взаимодействия?
Брокеры сообщений уместны: а) в распределенных системах, б) для обслуживания очередей обмена сообщениями между несколькими компонентами системы.
Тут не нужен сетевой уровень обмена, все процессы находятся в памяти одного севера и каждая очередь используется даже не для обмена, а для простой передачи сообщений от одного процесса к другому, т.е. между всего двумя процессами.
И придумывать тут особо ничего не надо, по сути любая таблица в БД с автоинкрементным ID или полем даты добавления записи - это уже очередь, в конец которой один процесс может добавлять, а другой - вынимать сообщения из начала.
Требования я сам себе ставил: простота, надежность, расширяемость, масштабируемость.
Из лучших практик - это разделение бота на отдельные, параллельно работающие сервисы, взаимодействующие между собой через обработку очередей сообщений.
Вдохновлялся я пожалуй - устройством и работой пулемета Maxim :)
Я полагал, что описываемая архитектура бота настолько проста, что достаточно текста, да и художник из меня - не очень, но раз надо графику, то вот что у меня получилось:
На 10000 семей каждый раз количество мальчиков и девочек получается примерно одинаково — по 10000 соответственно. При этом иногда получаются семьи, где есть и по 16 девочек, вот например в таком результате:
Array
(
[0] => 5038
[1] => 2393
[2] => 1291
[3] => 640
[4] => 323
[5] => 169
[6] => 73
[7] => 39
[8] => 23
[9] => 5
[10] => 5
[16] => 1
)
d=10038
m=10000