Jump to content

    
Sign in to follow this  
Alt.F4

Контрольная сумма массивов с любым порядком следования чисел

Recommended Posts

Вопросы:

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...]

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

Edited by controller_m30

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
5 hours ago, Alt.F4 said:

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

И сумма.

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

Share this post


Link to post
Share on other sites
1 час назад, Alt.F4 сказал:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 бит, пусть и  нестандартно. При больших объемах хранения-траффика-вычислений такой подход вполне может иметь право быть.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this