Push и Pull ingest файлов MCData через xMB: это ещё не способ получения уведомлений клиентом
В схеме MCData встречаются Push и Pull для доставки уведомлений, а в файловом MBMS сценарии — Push и Pull ingest. Похожие слова не означают одну и ту же операцию. Ingest относится к поступлению файла в инфраструктуру распространения, а не непосредственно к уведомлению или скачиванию на пользовательском устройстве.
Кто получает файл на этом этапе
В описанном Pull ingest BM-SC получает сведения о файле, включая URL, по которому его нужно забрать, и может использовать earliest fetch time. В Push варианте сервер MCData получает от BM-SC адрес для размещения файла и передаёт содержимое через xMB-U.
Таким образом, направления инициативы различаются на участке подготовки MBMS распространения. Отсутствие прямого запроса телефона к исходному content server не объясняет этот этап: конечный клиент ещё не является рассматриваемой стороной ingest обмена.
Планирование не равно доставке
В процедуре учитывается последовательность установления MBMS услуги и подготовки получателей. Поэтому предоставленная ссылка или успешная передача в BM-SC ещё не подтверждают, что файл дошёл до каждого клиента. После ingest требуется фактическое распространение и проверка результата.
Earliest fetch time также нельзя считать временем гарантированного завершения. Поле относится к возможности начала соответствующего получения инфраструктурой. Его смысл следует сохранять отдельно от целевого срока доставки и отчёта downloaded.
Как проверить выбранный режим
В тестовой схеме фиксируют ingest mode и роли компонентов. Для Pull наблюдают передачу нужной ссылки и реальное получение содержимого BM-SC. Для Push — возвращённый адрес размещения и фактическую отправку файла сервером MCData. Используют известный объект, чтобы сопоставить содержимое.
Затем отдельным этапом подтверждают MBMS получение на согласованном составе клиентов. Нельзя принять весь сценарий по одному успешному серверному загрузочному запросу. Если заявлены оба ingest режима, их проверяют раздельно.
В отчёте полезно рисовать путь самого файла и путь служебных сведений. Это помогает не смешать notification endpoints с адресами ingest и не применить правильный URL на неверном участке.
Такой разбор делает одинаковые термины понятными через роли и направление передачи. Push или Pull всегда нужно читать вместе с тем, какой объект, откуда и кто получает. Для файловой услуги это позволяет локализовать проблему подготовки распространения отдельно от проблем уведомления и конечной MBMS доставки.
