Lossless communication MCData: какие условия нужны для сохранения недоставленных данных
Термин lossless communication в описании MCData легко прочитать как обещание, что любые данные никогда не потеряются. В рассматриваемой архитектуре речь идёт о конкретном механизме обслуживания с использованием хранилища сообщений. Для его работы нужны предусмотренные настройки и действующая пользовательская учётная запись. Одного наличия сети MCData недостаточно.
Открыть схему в полном размере
Что должно быть подготовлено
В стандарте перечислены условия: услуга lossless предусмотрена для пользователя, имеется действительная учётная запись message store, разрешена соответствующая конфигурация сохранения и пользователь запросил сохранение коммуникации. Эти условия необходимо проверять совместно.
Поэтому рекламная отметка о поддержке функции и реальная активная настройка конкретного пользователя являются разными фактами. Если хранилище не подготовлено или сохранение не включено для нужного сценария, нельзя выводить ожидаемое поведение из одного названия режима.
Как используется хранилище
Для настроенной индивидуальной коммуникации данные, которые нельзя доставить сразу, становятся доступными через личную область получателя. Для настроенной группы учитывается также состояние affiliation: отсутствовавшему в ней участнику коммуникация предоставляется через его персональную учётную запись. Обычная доставка активным участникам и последующее получение сохранённого содержимого требуют разных наблюдений.
Это не физическая гарантия отсутствия любых сбоев оборудования, хранения или приложения. Механизм описывает предусмотренную судьбу коммуникации при выполнении условий. Его реальную работу и эксплуатационные ограничения подтверждают в конкретной системе.
Как испытать обещанную функцию
Сначала фиксируют состояние всех необходимых настроек тестового пользователя. Затем отправляют известное сообщение при доступном адресате и отдельно — когда предусмотренный сценарий требует сохранения для последующего получения. Проверяют объект в message store и результат на устройстве после восстановления доступности.
Отдельный тест проводят для участника группы, который не был affiliated в момент отправки, если такой случай входит в требования проекта. Состав группы и состояние пользователя должны быть записаны заранее, иначе невозможно определить, кому действительно полагалась коммуникация.
В отчёте сохраняют идентификатор сообщения, состояние сервиса и путь получения результата. Подтверждение депонирования в хранилище не следует автоматически называть прочтением на терминале; это отдельное событие.
Такой подход превращает общее слово lossless в проверяемую функцию. Заказчик получает подтверждение конкретных сценариев и понимает, какие настройки необходимы для их повторения. Если хотя бы одно условие отсутствует, ограничение видно до эксплуатации, а не обнаруживается после исчезновения ожидаемого сообщения.
