Очередное днище от сбербанка⁠⁠

Понапридумывали, я пиздюком спаял коммутатор на трех абонентов(телефонов стационарных то не у всех было) и с друзьями пиздил, помоему даже в режиме,, конференция"(так штоль щас называетца? )

Грамм 300 со стандартным аккумулятором.

Он, как и катушечник, колонки, денди, сега, кампункеры ямаха и БК, винил и подобное лежат на консервации в гараже и ждут момента, когда я гараж в холостяцкую берлогу превращу

Спасибо, мне приятно, я старался написать доступно неспециалисту.

Это я еще сильно упростил. HLR вообще могут иметь распределенную структуру и не быть представлены в сети в дискретном виде, это может быть (и обычно бывает) распределенная сеть СУБД. Кроме того, я не уверен, что HLR получают IMEI аппарата, технически им это нахрен не нужно, их задача - ограничение или разрешение на сервисы абонента и тарификация. AUC (центры авторизации - вот то, что собственно проверяет абонента и до кучи формирует ключи шифрования в сети) и собственно каждый из этих кирпичиков, главным образом выполняет, как правило, строго свою функцию и только. Вмешательство или контроль в их работу не очень просто добавить, это очень дорогие, сертифицированные и специально защищенные системы с ограниченными возможностями модификации.

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

Однако от себя скажу, что перегруз и в самом деле случается. У систем, которые мы казалось бы ожидаем видеть устойчивым именно к массовому обслуживанию, а однако же на объёмах явно не столь огромных. Допустим, возьмём банк ВТБ. Большой банк, много клиентов. Вот какие проблемы тут от массовости могут быть? А есть. Если сделать через их систему дистанционного обслуживания всего-то пару сотен списаний с карты на счёт, система станет шевелиться очень-очень медленно. Хотя казалось бы миллионы клиентов обслуживаются, и уж явно не испытывают проблем если несколько сотен из них в течение часа проведут какие-то операции. А вот гляди-ка, на одном клиенте это создаёт повышенную нагрузку. Предположу, что связано это с тем, что даже в собственный процессинг данные для окончательного списания выгружаются не моментально, а копятся и уходят некими порциями. Возможно, буфер для хранения именно таких недоисполненных операций не очень велик, а выгрузка, помнится, в будни там происходит раз в 2 часа. Если же пойти дальше и нагенерировать такие списания в виде отложенных да ещё и запланированных по расписанию, то окажется, что где-то около 2000 в календарные сутки наступает совсем предел. Все, что сверх этого, не могут вообще быть исполнены текущим днём и переоткладываются на следующий. Я не доводил до ситуации, когда пул отложенных каждый день рос за счёт всё новых и новых распоряжений (я не столь жестокий экспериментатор), а в этом случае могли выплыть ещё какие-то спецэффекты, которые явно до этого вообще никто не видел. Но и так позвонили и попросили умерить пыл.

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