Зачем всё так сложно: постановка и архитектура

[Dhwtj]

Ай ай

Оказалось, реальная ситуация не совпала с идеальной моделью. Пришлось усложнять, pity

Но зачем вы опять полезли в технологический стек, подробности реализации?

Рано ещё

[ETCDema]

Собственно, для этого и нужен был разбор реальной ситуации до реализации - чтобы внести поправки, пока это недорого. Идеальная модель как раз и проверяется практикой, и хорошо, что это произошло на этапе постановки, а не во время соревнования.

Здесь ещё нет реализации, только подготовка к ней и перечисляю то, что уже явно потребуется.

[Dhwtj]

чем происшествие отличается от отказа в протоколе: оба DNF или происшествие отдельная строка?

обратный отсчёт на старте кто ведёт, приложение по плановому времени или судья вручную?

Непонятно как происходит синхронизация. Непосредственно перед стартом клиент запрашивает время сервера? А пинг?

Протокол вроде фиксирует судья. А опротестовать можно?

То есть мы фиксируем события, которые рождаются на клиенте и приезжают на сервер с учётом поправки на синхронизацию? Как долго ждём? Интернет пропал и всё, события не дошли. Значит, может быть состояние забег не состоялся? Или такого просто выкинут из забега?

Это пока всё про бизнес правила

На клиенте только рекомендуемое время старта и не влияет на отметку фактического времени старта? А если стартовал уже вне окна? Понятие окна старта вообще тут есть? Оно заранее известно или просто судья решает пустить или нет?

[Dhwtj]

Или фактическое время старта никто не меряет, главное чтобы не стартовал раньше планового времени?

[ETCDema]

Я описываю любительские соревнования, поэтому часть требований намеренно упрощена. Про время: в статье прямо сказано, что все устройства организаторов и судей должны быть синхронизированы перед стартом. Для нашего уровня точности этого достаточно.

События, которые рождаются на клиенте, приезжают на сервер, и по мере их поступления сервер пересчитывает текущую картину.

Обратный отсчёт на старте ведёт приложение, запускает его организатор, когда участник выходит на старт. Плановое время нужно участникам, чтобы они сами подходили на старт в своём порядке. Фактическое время старта - когда счетчик дошел до нуля. Если пересек линию раньше, то судья возвращает участника на старт и аннулирует событие неудачного старта. Если поехал чуть позже - что ж, где-то придется ускоряться.

Пока организатор не зафиксировал протокол, события могут добавляться и вручную, и досылаться, если у судьи терялась сеть. На клиенте они сохраняются локально и отправляются повторно до получения подтверждения от сервера, так что потеря событий исключена. Естественно, это требует контроля повторного получения на стороне сервера.

[PAL_habr]

Если вопрос в том чтобы данные передать сначала на сервер, а потом сделать итоговые бюллетени, и точность нужна не на уровне сотых секунды, то никакая синхронизация времени устройств не нужна. Устройство просто фиксирует события в локальном времени устройства, а когда передает данные на сервер, одновременно передает и свое текущее локальное время. Сервер определяет разницу текущего времени устройства со своим временем и вносит корректировку для времени событий.

[ETCDema]

На самом деле все проще: в событиях фиксируется локальное время устройства, никакой разницы с сервером считать не нужно. Синхронизация времени на устройствах нужно что бы разница во времени между устройствами была минимальной т.к. устройства организаторов являются в нашем случае доверенными. Для этого достаточно установить приложение для синхронизации времени.