Даже для eSim необходима физическая карта. Но задачи eSim это скорее про RFM (remote file management), чем про RAM. Хотя с помощью RAM для eSim заливаются апплеты управления IMSI, в случае когда необходим так называемый Multi IMSI.
Может инициировать по таймеру, но к единственному endpoint http-ota endpoint (который контролируется оператором связи), а не на любой адрес в публичной сети.
Данная возможность не очень часто используется, в основном для задач управления апплетами используется прямая инициализации сессии. Через SMS транспорт отправляется триггер установки соединения. Естественно, это secured packet и естественно доступ только через ключи безопасности, которые уникальны для каждой карты (KIC, KID, KICKey, KIDKey)
К OS и FS нет. Весь диалог с апплетами построен через отправку C-APDU и получение R-APDU.
Но у апплета есть возможность иницировать отправку SMS, USSD, открытия браузера на нужной странице, совершения голосового вызова.
Доступ в интернет в общем смысле отсутствует, но есть возможность работы по TCP с http ota (доступ настраивается отдельно, используется TLS-PSK свой для каждой карты), в том числе инициализация сессии самим апплетом по таймеру (настраивается отдельно).
Но для всех операций нужны ключи безопасности и настроенный SMSC.
Сразу вспомнил мем "как нарисовать сову". Код примера носит иллюстративный характер. В репозитории еще есть и серверная часть, которая эти запросы обрабатывает. В самом начале я придумал дополнительные условия, тем самым искусственно усложняя ситуацию, чтобы показать удобство интерфейсов.
Я думаю, для отправки обычных SMS через SMPP пользователь может ограничиться https://hexdocs.pm/smppex/SMPPEX.html#module-smppex-esme-sync.
Но если нужно решить более сложные задачи, то необходимы знания. В этом случае прямая дорога в чтение спецификаций в поисках ответов на многие вопросы: какие нужны ton/npi для тех или иных разновидностей адресов, UDHI в esm_class, работа с UDH, набор кодировок, multipart SM и многое другое. Но как говорится, это отдельная история.
Для телеком систем гораздо важнее скорости компиляции и развертывания одним исполняемым файлом является вопрос надежности. Я возможно пропустил, но как вы решаете его и сколько у вас девяток?
Применяются ли какие либо стратегии обработки отказов и восстановления компонентов и системы в целом? Деревья супервизоров для процессов/потоков?
Ну и выбор go с его GC… уже сталкивались на проде с проблемами с ним?
Эксперимент задумывал, как проверку функционального подхода в более или менее сложном проекте. При этом все от архитектуры до пользовательских интерфейсов реализовывал сам.
В демку можно залогиниться, автоматом начислится баланс и можно поторговать. Например https://trade.vonmo.com/exchange/S1S2 без market-maker.
В декларации спейсов под списки, я привел только limit и market, для остальных типов ордеров аналогично выделяется спейс, контроллер рынка следит за условиями активации ордеров и при выполнении условия переводит ордер в limit или market в зависимости от его типа.
Спасибо за вопрос. Чтобы добиться надежности, нужна репликация. Tarantool поддерживает только асинхронную, которая по понятным причинам не подходит для финансовых систем. Разработчики обещали выкатить поддержку в версии 2.3.1, которая должна была выйти 1 декабря, но воз и ныне там.
Чтобы обойти это ограничение, для MVP я сделал логическую репликацию. Для каждого рынка можно подключить N хранилищ (пара pg, tarantool). После падения тарантула, хранилище будет помечено аварийным и контроллер продолжит работу с оставшимися.
Если рынок сконфигурирован на работу только с одним хранилищем, то после падения тарантула, контроллер будет выдавать сообщение о недоступности сервиса и ждать пока хранилище восстановят.
Внутри платформы все по tcp. Erlang дает full mesh. Тоже стало любопытно про задержки. У меня отложилась в памяти цифра end-to-end до 30 мкс.
Сейчас измерил req-resp на локали внутри докера. Sequential 20933 cycles/s, что эквивалентно round trip latency = 47,7мкс. Плюс будет tcp stack latency. На моем ядре и машине он равен ~28 мкс. Плюс будет сетевая end-to-end latency 7 мкс в случае 10 GigE и меньше 1,5 мкс для InfiniBand. Итого в конкретном случае round tip latency будет 89,7 мкс и 78,7мкс соответственно.
Если говорить про задержку доставки ордера от входа в систему до обработчика книги, то это end-to-end latency и в конкретном случае она будет от 44 мкс до 39 мкс соответственно.
Да, не 35 мкс. Похоже, чтобы добиться 30 мкс нужно сидеть в ядре, а не user space.
вот да… информации мало)
Насчет скорости. Раунд трип, от момента приземления ордера на платформе до момента, когда ордер попадает к обработчику рынка (order matching engine) и тот выдает сигнал, составляет около 30-35 мкс. В основном, это время тратится в mq построенном поверх erlang distributed, который в свою очередь бегает поверх tcp. Хотя бы с этой метрикой определились, что она примерно, как у всех)
Tarantool чаще радует. Огорчает, что пока не завезли синхронную репликацию. Ну и к явному управлению транзакциями есть вопросы.
Эксперимент, как раз и задуман, чтобы понять какие технологии и дизайн применять в реальных проектах. Очень интересна конструктивная критика и реальный опыт разработки.
Поделитесь пожалуйста примерным набором технологий и дизайном, которые обеспечивают поток 5-7к закрытых сделок или частичных закрытий в секунду на рынок (с полной фиксацией данных и уведомлением участников), и потенциально позволяющие обслуживать сотни и тысячи рынков.
чуть ниже дал ссылку на отличный доклад, который ответит на ваши вопросы и даст общее понимание базовых вещей
Всем кто заинтересовался темой SIM решений, рекомендую ознакомиться с докладом Антона Трошина: https://www.youtube.com/watch?v=CumGQSX6_ws
Чтобы найти подробный ответ на вопрос, можно почитать про smart cards. Если коротко, то все упирается в безопасность итогового решения.
Даже для eSim необходима физическая карта. Но задачи eSim это скорее про RFM (remote file management), чем про RAM. Хотя с помощью RAM для eSim заливаются апплеты управления IMSI, в случае когда необходим так называемый Multi IMSI.
Может инициировать по таймеру, но к единственному endpoint http-ota endpoint (который контролируется оператором связи), а не на любой адрес в публичной сети.
Данная возможность не очень часто используется, в основном для задач управления апплетами используется прямая инициализации сессии. Через SMS транспорт отправляется триггер установки соединения. Естественно, это secured packet и естественно доступ только через ключи безопасности, которые уникальны для каждой карты (KIC, KID, KICKey, KIDKey)
К OS и FS нет. Весь диалог с апплетами построен через отправку C-APDU и получение R-APDU.
Но у апплета есть возможность иницировать отправку SMS, USSD, открытия браузера на нужной странице, совершения голосового вызова.
Доступ в интернет в общем смысле отсутствует, но есть возможность работы по TCP с http ota (доступ настраивается отдельно, используется TLS-PSK свой для каждой карты), в том числе инициализация сессии самим апплетом по таймеру (настраивается отдельно).
Но для всех операций нужны ключи безопасности и настроенный SMSC.
JFI: для разработки апплетов и отладки OTA очень удобно использовать SIMtrace2 плату
Мир проприетарных технологий он такой, welcome) В моей статье как раз дан вектор куда копать, не более
Спасибо за развернутый комментарий!
Сразу вспомнил мем "как нарисовать сову". Код примера носит иллюстративный характер. В репозитории еще есть и серверная часть, которая эти запросы обрабатывает. В самом начале я придумал дополнительные условия, тем самым искусственно усложняя ситуацию, чтобы показать удобство интерфейсов.
Я думаю, для отправки обычных SMS через SMPP пользователь может ограничиться https://hexdocs.pm/smppex/SMPPEX.html#module-smppex-esme-sync.
Но если нужно решить более сложные задачи, то необходимы знания. В этом случае прямая дорога в чтение спецификаций в поисках ответов на многие вопросы: какие нужны ton/npi для тех или иных разновидностей адресов, UDHI в esm_class, работа с UDH, набор кодировок, multipart SM и многое другое. Но как говорится, это отдельная история.
n.b. Про телеком это вы в точку.
Для телеком систем гораздо важнее скорости компиляции и развертывания одним исполняемым файлом является вопрос надежности. Я возможно пропустил, но как вы решаете его и сколько у вас девяток?
Применяются ли какие либо стратегии обработки отказов и восстановления компонентов и системы в целом? Деревья супервизоров для процессов/потоков?
Ну и выбор go с его GC… уже сталкивались на проде с проблемами с ним?
Эксперимент задумывал, как проверку функционального подхода в более или менее сложном проекте. При этом все от архитектуры до пользовательских интерфейсов реализовывал сам.
В демку можно залогиниться, автоматом начислится баланс и можно поторговать. Например https://trade.vonmo.com/exchange/S1S2 без market-maker.
Попробую найти время и подготовить материал
Спасибо за информацию!
В декларации спейсов под списки, я привел только limit и market, для остальных типов ордеров аналогично выделяется спейс, контроллер рынка следит за условиями активации ордеров и при выполнении условия переводит ордер в limit или market в зависимости от его типа.
Спасибо за вопрос. Чтобы добиться надежности, нужна репликация. Tarantool поддерживает только асинхронную, которая по понятным причинам не подходит для финансовых систем. Разработчики обещали выкатить поддержку в версии 2.3.1, которая должна была выйти 1 декабря, но воз и ныне там.
Чтобы обойти это ограничение, для MVP я сделал логическую репликацию. Для каждого рынка можно подключить N хранилищ (пара pg, tarantool). После падения тарантула, хранилище будет помечено аварийным и контроллер продолжит работу с оставшимися.
Если рынок сконфигурирован на работу только с одним хранилищем, то после падения тарантула, контроллер будет выдавать сообщение о недоступности сервиса и ждать пока хранилище восстановят.
Сейчас измерил req-resp на локали внутри докера. Sequential 20933 cycles/s, что эквивалентно round trip latency = 47,7мкс. Плюс будет tcp stack latency. На моем ядре и машине он равен ~28 мкс. Плюс будет сетевая end-to-end latency 7 мкс в случае 10 GigE и меньше 1,5 мкс для InfiniBand. Итого в конкретном случае round tip latency будет 89,7 мкс и 78,7мкс соответственно.
Если говорить про задержку доставки ордера от входа в систему до обработчика книги, то это end-to-end latency и в конкретном случае она будет от 44 мкс до 39 мкс соответственно.
Да, не 35 мкс. Похоже, чтобы добиться 30 мкс нужно сидеть в ядре, а не user space.
Насчет скорости. Раунд трип, от момента приземления ордера на платформе до момента, когда ордер попадает к обработчику рынка (order matching engine) и тот выдает сигнал, составляет около 30-35 мкс. В основном, это время тратится в mq построенном поверх erlang distributed, который в свою очередь бегает поверх tcp. Хотя бы с этой метрикой определились, что она примерно, как у всех)
Tarantool чаще радует. Огорчает, что пока не завезли синхронную репликацию. Ну и к явному управлению транзакциями есть вопросы.
Поделитесь пожалуйста примерным набором технологий и дизайном, которые обеспечивают поток 5-7к закрытых сделок или частичных закрытий в секунду на рынок (с полной фиксацией данных и уведомлением участников), и потенциально позволяющие обслуживать сотни и тысячи рынков.