а как шардирование поможет балансировать нагрузку?
поток транзакций не равномерно между счетами же делится, какие-то более активные, какие-то менее, соответственно какие-то шарды будут больше нагружены, а какие-то меньше. это, конечно, лучше чем ничего, но на балансировку не тянет, как минимум из-за отсутствия возможности управлять распределением нагрузки.
10-60 секунд это время репликации всей процессинговой сети, т.е. зависит от сети между узлами.
по поводу входящих средств, они «болтаются» как отправленные, и время их попадания на все узлы(когда они могут быть задействованы в транзакциях) зависит от времени репликации в сети.
то есть практически, если мы хотим со счета с большим количеством входящих(на этот счет) транзакций перевести средства, то мы имеем достаточно информации, чтоб определить на каком узле будет такая транзакация проведена. Соответственно, можем отправить туда запрос о том, сколько в конкретный момент средств доступно (сколько входящих транзакций среплицировалось на этот узел), и оценивать текущий баланс счета-источника (на который входящие средства перечисляются).
Транзакции, которые маршрутизируются на упавшие узлы дропаются. (хотя возможны варианты)
Сплитбрейн в привычном смысле здесь не особо возможен, но если имеется ввиду форк цепочки, то чтоб это произошло нужно начать переназначать DHT диапазоны, но «само» это случиться не может. Но если даже и случится, то по цепочкам можно проследить когда это случилось и какие транзакции в таком состоянии были проведены. Транзакций таких вряд ли будет много, так как из-за неконсистентности цепочек проводка встанет и все.
>все транзакции одного и того же клиента попадают на один и тот же хост,
>При условии, что все транзакции одного и того же клиента попадают на один и тот же хост,
Нет. Узел, который будет обрабатывать транзакцию индивидуален для каждой отдельной транзакции, так как рассчитывается от хеша каждой предыдущей обработанной транзакции. (если узлов не много, то возможны частные случаи когда это будет один и тот же узел, то только из-за того, что хеши предыдущей транзакции и предпредыдущей будут находиться в DHT диапазоне этого узла)
>Чем принципиально такой вид load balancing-а отличается от обычного применения affinity (sticky sessions) на load balancer-ах
мне трудно ответить на этот вопрос, так как я общего не вижу. Можете по пунктам перечислить, если не сложно?
>Не особо понятно откуда нод понимает, что у него устарела версия цепочки. Из чего «из этого» следует
из того, что хеш последней обработанной транзакции на узле, который отправил в сеть запрос не транзакцию (этот хеш в запросе) отсутствует на узле-получателе, который должен транзакцию обработать.
если много лоченых (с просьбой сменить пароль), то скорей всего это ботоводские базы украденных дохлых аккаунтов, которые ужа давно спалились, как взломанные. И ботоводы эти списки выбрасывают, чтоб с капчей не заморачиваться.
если принимать во внимание, что это форк того же OpenSSL, работая над которым, люди как-то не сообщали о найденных и исправленных багах (коих в openssl исправляют каждый месяц пачку), да хотя бы о портировании патчей, то можно предположить, что профессионалы они в чем-то другом.
а вы залили iOS приложение? там просто непосредственно исполняемый файл DRM защищен, который пока вне устройства никто публично не научился снимать. Так что анализатор смотрит на все, что есть помимо бинарника, plist, xml,sqlite и прочее.
Свое, конечно. Моя конструкция на год раньше их исследования появилась. В playdrone «грепают» декомпилированный код, я, помимо этого, ещё изучаю содержимое sqlite баз, xml, смотрю подозрительные файлы. Но вот идея с elasticsearch мне в плане удобства понравилась, сейчас смотрю как её лучше встроить.
>Хотелось бы аналогичное для iOS.
ссылки с itunes тоже работают, анализ базовый тоже проводится.
>это хорошо или плохо?
Если нет вкладки багов, то значит лютых багов не найдено. Рекомендую заглянуть в секцию suspicious files, там частенько можно увидеть то, чего в приложении не нужно.
поток транзакций не равномерно между счетами же делится, какие-то более активные, какие-то менее, соответственно какие-то шарды будут больше нагружены, а какие-то меньше. это, конечно, лучше чем ничего, но на балансировку не тянет, как минимум из-за отсутствия возможности управлять распределением нагрузки.
по поводу входящих средств, они «болтаются» как отправленные, и время их попадания на все узлы(когда они могут быть задействованы в транзакциях) зависит от времени репликации в сети.
то есть практически, если мы хотим со счета с большим количеством входящих(на этот счет) транзакций перевести средства, то мы имеем достаточно информации, чтоб определить на каком узле будет такая транзакация проведена. Соответственно, можем отправить туда запрос о том, сколько в конкретный момент средств доступно (сколько входящих транзакций среплицировалось на этот узел), и оценивать текущий баланс счета-источника (на который входящие средства перечисляются).
Сплитбрейн в привычном смысле здесь не особо возможен, но если имеется ввиду форк цепочки, то чтоб это произошло нужно начать переназначать DHT диапазоны, но «само» это случиться не может. Но если даже и случится, то по цепочкам можно проследить когда это случилось и какие транзакции в таком состоянии были проведены. Транзакций таких вряд ли будет много, так как из-за неконсистентности цепочек проводка встанет и все.
>При условии, что все транзакции одного и того же клиента попадают на один и тот же хост,
Нет. Узел, который будет обрабатывать транзакцию индивидуален для каждой отдельной транзакции, так как рассчитывается от хеша каждой предыдущей обработанной транзакции. (если узлов не много, то возможны частные случаи когда это будет один и тот же узел, то только из-за того, что хеши предыдущей транзакции и предпредыдущей будут находиться в DHT диапазоне этого узла)
>Чем принципиально такой вид load balancing-а отличается от обычного применения affinity (sticky sessions) на load balancer-ах
мне трудно ответить на этот вопрос, так как я общего не вижу. Можете по пунктам перечислить, если не сложно?
>Не особо понятно откуда нод понимает, что у него устарела версия цепочки. Из чего «из этого» следует
из того, что хеш последней обработанной транзакции на узле, который отправил в сеть запрос не транзакцию (этот хеш в запросе) отсутствует на узле-получателе, который должен транзакцию обработать.
Быстро POC в оборот пошел :)
github.com/hackappcom/ibrute
>Хотелось бы аналогичное для iOS.
ссылки с itunes тоже работают, анализ базовый тоже проводится.
>это хорошо или плохо?
Если нет вкладки багов, то значит лютых багов не найдено. Рекомендую заглянуть в секцию suspicious files, там частенько можно увидеть то, чего в приложении не нужно.