LINUX.ORG.RU

Алгоритм актуализации передаваемой информации в распределенных системах

 


0

1

Тут очень много специалистов, может подскажет кто, уже неделю не могу придумать надежную систему передачи информации в системе «клинт-клиент».

Представьте, у нас есть информация об определенных вещах. Допустим айди вещи, количество конкретно этого предмета. Каждый клиент может стать «сервером», расшаривая свои вещи другим клиентам. А может быть ретранслятором - не расшаривая свои вещи, но передавая чужие остальным клиентам.

Передавать можно по одной вещи за раз. Принимать тоже придется по одной и объединять все это в единую таблицу.

Абстрактно представим, что у меня есть три шапки и кроссовки и два пальто. Я делаю себя сервером. Теперь каждый другой клиент может меня просканировать и увидеть, что у меня три шапки, кроссовки и два пальто. Он делает себя ретранслятором. Теперь если третий клиент начнет сканирование, то одновременно мою талицу будем отдавать и я и он.

Допустим, он тоже делает себя сервером. Теперь и у меня и у него две таблицы: моя и его. При сканировании третьим клиентмо мы оба отдаем и его и мою таблицы.

И возникает проблема. Как получать действитеьно уникальную и актуальную инфу? Допустим, при каждой передаче каждой вещи мы прибавляем имя - чья это вещь. Что еще? Как актуализировать каждую вещь? Чтобы при сканировании был приоритет приема таблиц с вещами. Например, от владельца берем, от не владельца - приоритет ниже.

Но прием то и отдача происходят одновременно. Нужны какие то уникальные айди для каждой вещи? Но как узнать ее уникальность и не дублировать?

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

Как можно передавать и актуализировать все надежно?

★★★★★

Последнее исправление: CrX (всего исправлений: 2)

Обычная дедупликация сообщений с приоритетом, аля:

{
  "itemId": "hat",          // тип предмета
  "ownerId": "alice",       // владелец (не отправитель)
  "quantity": 3,
  "version": 7,             // владелец сам инкрементит при изменении
  "timestamp": 1709123456,  // время изменения по часам владельца
  "hopCount": 0             // счетчик, 0 = от самого владельца, 1 = через один ретранслятор и т.д.
}

Каждый ретранслятор увеличивает счетчик на 1.

При получении данных алгоритм сравнения довольно простой:

  1. Оставляем ту, у которой version выше
  2. Если version одинаков, то берём ту, у которой hopCount ниже
  3. Если version одинаков, hopCount одинаков, но timestamp выше, то берём новую
  4. Если всё одинаково, то игнорируем

В качестве GUID достаточно взять itemId + ownerId.

Obezyan
()
Ответ на: комментарий от Obezyan

Ага, до передачи времени я додумался, а до инкрементации версии нет.

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

Так стоп. Надо три типа сообщений. 1) Старт отправки 2) Середина 3) Конец отправки. Так мы сможем отличать …а зачем - мы и так различаем по отправителю.. Хм..

Ладно, начинаем отправлять по одному предмету. Если клиент видит айди отправки - добавляет во временную новую таблицу, пока не встретит айди завершения. На завершении проверяет версию. Если версия более новая - заменяем постоянную таблицу этой временной.

Допустим, у нас два ретранслятора.. Если инфа идентична - просто оставляем последнего. Если инфа разная - оставляем более новую версию.

При этом и сами ретрансляторы сравнят инфу и оставят более актуальную версию.

Так же всегда безусловно оставляем версию того, чья таблица принадлежит ему - это всегда сама актуальная инфа.

Ага, кажется понял, спасибо.

LightDiver ★★★★★
() автор топика
Ответ на: комментарий от Obezyan

До меня дошло, что по сути версия то просто дублирует время. А время у меня уже было. Просто я сделал временные рамки приема 5 секунд, а передача длилась 9 секунд. И у меня возникали несоответствия.

Ну да ладно, версия даже надежнее.

Всем спасибо.

LightDiver ★★★★★
() автор топика
Ответ на: комментарий от cobold

Если есть версия, то время особо и не нужно

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

Obezyan
()