[Alt.F4 1]

Разброс от 1 мс до 24 часов, т.е. от 1 до 86400000.

[controller_m30 1]

Вопросы:

1. А по какой причине два сервера путают очерёдность временных меток? И насколько может запоздать любая метка от её истинной очерёдности (на 10, 100, 1000 мест в очереди)?

 

2. Массивы имеют фиксированную длину (напр. точно 1Мб), или заканчиваются на границе суточного перехода (с 23.59 на 0.00)?

 

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

 

Если массивы фиксированной длины, то на границе массивов путаница очереди меток снова спутает всё. Например, границы двух массивов:

Первый сервер: [...1,2,3,4]_______[5,6,7,8...]

Второй сервер:  [...3,4,5,6]_______[1,2,7,8...]

И тоже получается несовпадение КС массивов, независимо от способа расчёта.

Изменено 29 июня, 2020 пользователем controller_m30

[Alt.F4 1]

controller_m30, нет смысла углубляться в механизм синхронизации, вопрос заключается только в способе расчета КС для неупорядоченных чисел

[ae_ 2]

5 hours ago, Alt.F4 said:

Выходит, остаётся только XOR...

И сумма.

Судя по вашей ссылке на хабр, там есть сравнение, сумма лучше, чем XOR.

[jcxz 184]

1 час назад, Alt.F4 сказал:

controller_m30, нет смысла углубляться в механизм синхронизации, вопрос заключается только в способе расчета КС для неупорядоченных чисел

Если "не углубляться" и считать простым набором произвольных чисел, то ничего и не получить кроме слабой суммы.

[Alt.F4 1]

Да углубляться особо и некуда, в массивах 64-битные числа (UNIX-метки времени в мс), массивы разбиты по суткам, т.е. в одном массиве может быть от 1 до 8.64млн меток в одном массиве, но это критические значения, в среднем порядка 100тыс. в массиве.

[Ruslan1 16]

On 6/29/2020 at 3:08 PM, Alt.F4 said:

Да углубляться особо и некуда, в массивах 64-битные числа (UNIX-метки времени в мс), массивы разбиты по суткам, т.е. в одном массиве может быть от 1 до 8.64млн меток в одном массиве, но это критические значения, в среднем порядка 100тыс. в массиве.

Кстати, почему бы не использовать для временных меток нестандартный, но вполне достаточный uint32_t ?  На 130 лет хватит, начиная с 1970. 

Уже экономия в два раза, и переход от 64-битной арифметики на 32-битную.

Upd: Хотя, если у Вас там возможно время до 1970, то не пойдет. Но может быть действительно можно остаться в рамках беззнакового 32 бит, пусть и  нестандартно. При больших объемах хранения-траффика-вычислений такой подход вполне может иметь право быть.

[Sergey_Aleksandrovi4 1]

Мне кажется, что на таких объёмах данных (400 кБайт) 32-битная контрольная сумма со слабым алгоритмом лишена смысла. Банальный счётчик элементов массива будет где-то рядом по надёжности.

[Alt.F4 1]

Счетчик и xor юзаем с самого начала, думали накинуть еще чего для надежности, но по всей видимости, вариантов и нету..

[AHTOXA 14]

Ну если вас устраивает такая (никакая) надёжность, то конечно, юзайте xor.

А вообще я так и не понял, почему нельзя сразу сортировать эти числа.