Ты для начала поищи тот API который делает переключение. Может на уровне его возможностей уже окажется что твоя идея нереализуема. Хотя-бы потому что будет рубить коннекты другой симки. А это наверное плохой кейс для направления трафика. Слишком деструктивное направление выходит. Впрочем я умолкаю. Больше по теме сказать как-бы и нечего.
Коллеги. Анализ подсистемы хранения - обречен на провал. Тоесть мы не сможем вывести свойство реляции или не-реляции из того как БД хранит данные на диске. Эта возможность может быть просто не заложена в формат хранения.
Мне кажется - более продуктивно не делить на 2 корзины а просто рисвать матрицу фич. Например у Кассандры будут такие-то фичи. У постгреса - другие. Часть этих фич будут пересекаться. Часть будут уникальны.
long_skinny_boy, нет не происходит. Но пользователи могут ставить софт без msi-инсталлера. Просто качают zip архив. Распаковывают. Вот какое тут событие? ХЗ.
eegmak, реконнект к вышкам - это особенность 3G-протокола. Но это вам не поможет вы ведь подключаетесь к другой сети. А это - цикл более глубокий чем просто перепрыгнуть с вышки на вышку в одной сети. Тем более что 3G делает это заранее.
Привести пример приложений не могу. Но почитайте про Ribbon https://github.com/Netflix/ribbon . Это сетевой программный балансер который используется Нетфликсом. Может какие-то идеи возникнут.
eegmak, да. Первое да. Я думаю что симкарта это хранилище ключей. Медленное. Ограниченное по циклам записи.
Второе - нет. Для смены оператора нужно сделать физически реконнект к другим радио-вышкам оборудования. И эта процедура в сто или в тысячу раз медленнее. Вкупе с ошибками и реконнектами.
Впрочем если в топик зайдет специалист по мобильным сетям - то я надеюсь он лучше прояснит вопрос. Но вообще в науке и технике считается что стационарный режим работы оборудования - самый благоприятный.
res2001, мне кажется тут нет точного ответа. Вот автор пишет дескыть "народ жалуется". Тоесть надо провести серию экспериментов над народом чтобы они там коллегиально решили например что для разработки лучше RDP - ибо среда IDE только текст передает. А для дизайна там например VNC поставить. Особенно если они там векторную графику рисуют и анимацию. Хотя если-бы я был дизайнер - то был бы в ужасе от такого решения конечно.
В сигнальных и управляющих протоколах типа ICMP, DHCP у нас вообще номер порта не указывается. Тоесть предполагается что в сети существует только один единственный сервис которых на хосте предлагает такую услугу.
Поэтому номера портов являются логическим объяснением почему они должны существовать для прикладного протокола. Иначе нельзя было-бы несколько подобных приложений поднимать на одном хосте.
Если два приложения будут работать одновремено (типичная ситуация для современных операционок) то твой маршрутизатор будет каждые несколько милисекунд переключать диспетчер туда-сюда. Беря во внимание время коннекта (несколько секунд) то вместо стабильного соединения мы получим постоянное включение-выключение. Это плохо видно в It-технологиях но зато хорошо заметно в электротехнике. Попробуй включать и выключать пылесос каждую секунду. Я гарантирую что он сгорит быстро от нестационарного режима работы.
Span4ev, по поводу ООП - это моё предположение. С позиции Java/Scala разработки. Возможно в Питонах на это вообще забивают. Тогда моя претезния просто не по адресу.
Да и еще. Есть такой забавный эффект. Память удвоили - а производительность приложения не удвоится.
Ну там +15 % будет к примеру. Кеши - теже самые. Скорость канала - таже.
AcTapD, идея с файлом - фигня полная. Как ты там поиск реализуешь? Линейный небось?
Между твоим приложением и LDAP можно поставить бесконечное количество баз и систем. Memcached, Redis, RocksDb. Все они обладают опцией TTL и подходят для кешей в временем жизни.
Но до того как брать эти технологии я-бы попробовал хранить записи в памяти сеанса бота. По ключевому слову LRU гуглится следующая штука https://pypi.org/project/python-lru/ посмотри. Может ее возможностей хватит и тебе не нужны будут другие инстанции. Все предположения относительно перформанса - остаются просто предположениями. Нужно запускать бота. Смотреть как он работает. Может тебе вообще кеш не нужен.
Твои рассуждения имеют изъян. Ты предполагаешь что дешевле качать базу LDAP и сохранять ее в файл и потом этот файл использовать, чем просто подключаться из бота к LDAP. Я не согласен с этой идеей.
Или может быть на самом деле проблема не в этом? Безопасность доступы то да сё.
Дерзай. Читай SDK.