Софт: бэкенд веб сервисов, «умный дом», прикладная часть драйверов и т. п.. Проекты совсем разные (в т.ч. и заказчики).
Пример:
В одном проекте: сервис, обменивающийся данными по сети с полезной нагрузкой в виде строки (авторизационый сервис).
В другом: схожий сервис, но данные не строковые, а различные числовые данные (int, uint, float и другие результаты замеров).
В будущем третьем: сервис уже с пользовательским типом (драйверная обертка).
Конечно, так или иначе это можно сделать. Но очень много одинаковых компонентов, отличающихся только типом в аргументах функций.
Тут не в теории дело, а чисто в практике: когда пишешь код под int, а в соседнем проекте потребуется string но с аналогичными операциями, копипаст начинает злить и мешать
Так, чтобы можно было реализовать строготипизированную работу с произвольными коллекциями без копипаста и с проверкой типов при компиляции (например очередь как в STL)
[ИМХО]
Единственно, чего не хватает в Go — generics. Хотя это, конечно, прямо соответствует идеологии упрощения читабельности (шаблонный код не всегда легко понимается).
[/ИМХО]
А смысл взламывать?
Насколько я понимаю идею, то карта не более чем уникальный ID, используемый для авторизации для определения электронного кошелька/аккаунта. Т.е. «взломать» можно не более чем просто номер, а изменить баланс уже нельзя, так как он хранится удаленно.
Это все моё ИМХО конечно, но если у кого есть больше информации прошу поделится.
Использование Ms SQL в качестве Message store для гарантированной доставки какую производительность обеспечивает? Хотя бы качественные оценки.
Вы сравнивали с другими шинами (GlassFish, Jboss, ActiveMQ и другими)?
Динамическое подключение/отключение узлов возможно? Допустим идёт долгий (сутками) расчёт без промежуточного сохранения, и не хочется потерять данные при отказе одного из узлов. Или добавить мощности «на ходу» за счёт подключения нового сервера
Такой вопрос: скриншоты настоящие или это качественный рендер только для рекламы? Если это реальная графика, то интересно было бы услышать, как вы делали работу с тенями, освещением и прочими эффектами в массовых битвах. По идеи, динамическое освещение должно лихо есть ресурсы компьютера, особенно при множестве объектов
Тем не менее, вы скорее всего правы, так как отсутствие каких-либо упоминаний в официальной документации, позволяет предположить, что их проект по реализации FAST не завершился (или был отменен).
Спасибо за уточнение.
Однако в ММВБ идет масштабная реструктуризация торговых решений. Возможно, взамен собственных нативных протоколов будет использоваться тот-же ITCH (исключительно предположение)
При высокочастотной торговли, операции кодирования и вычисления контрольной суммы тоже выполняются. Не только на клиентской части, но и в бирже.
Тем не менее, UDP канал обычно используют для получения данных о «стаканах» и прочей биржевой информации, так как эта информация обычно устаревает раньше, чем будет отправлен запрос на восстановление пропущенных сообщений.
Если отправляется заявка в биржу, то ее подтверждение (или отклонение) присылается обратно клиенту.
Если заявка была отправлена, а ответ потерялся, счетчик сообщений с биржи разойдется с клиентским (у биржи будет больше клиента).
Если заявка не была получена, счетчик сообщений так же разойдется (у клиента будет больше биржи).
Пример:
В одном проекте: сервис, обменивающийся данными по сети с полезной нагрузкой в виде строки (авторизационый сервис).
В другом: схожий сервис, но данные не строковые, а различные числовые данные (int, uint, float и другие результаты замеров).
В будущем третьем: сервис уже с пользовательским типом (драйверная обертка).
Конечно, так или иначе это можно сделать. Но очень много одинаковых компонентов, отличающихся только типом в аргументах функций.
Единственно, чего не хватает в Go — generics. Хотя это, конечно, прямо соответствует идеологии упрощения читабельности (шаблонный код не всегда легко понимается).
[/ИМХО]
Насколько я понимаю идею, то карта не более чем уникальный ID, используемый для авторизации для определения электронного кошелька/аккаунта. Т.е. «взломать» можно не более чем просто номер, а изменить баланс уже нельзя, так как он хранится удаленно.
Это все моё ИМХО конечно, но если у кого есть больше информации прошу поделится.
Вы сравнивали с другими шинами (GlassFish, Jboss, ActiveMQ и другими)?
Тем не менее, вы скорее всего правы, так как отсутствие каких-либо упоминаний в официальной документации, позволяет предположить, что их проект по реализации FAST не завершился (или был отменен).
Спасибо за уточнение.
Однако в ММВБ идет масштабная реструктуризация торговых решений. Возможно, взамен собственных нативных протоколов будет использоваться тот-же ITCH (исключительно предположение)
Тем не менее, UDP канал обычно используют для получения данных о «стаканах» и прочей биржевой информации, так как эта информация обычно устаревает раньше, чем будет отправлен запрос на восстановление пропущенных сообщений.
Если отправляется заявка в биржу, то ее подтверждение (или отклонение) присылается обратно клиенту.
Если заявка была отправлена, а ответ потерялся, счетчик сообщений с биржи разойдется с клиентским (у биржи будет больше клиента).
Если заявка не была получена, счетчик сообщений так же разойдется (у клиента будет больше биржи).