Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2008.04.13;
Скачать: [xml.tar.bz2];

Вниз

GUID - насколько уникален?   Найти похожие ветки 

 
Anatoly Podgoretsky ©   (2008-02-27 22:44) [40]

> Григорьев Антон  (27.02.2008 11:15:08)  [8]

Наезжали не из-за этого, локальная сеть с одинаковыми МАС адресами принципиально работать не может


 
Anatoly Podgoretsky ©   (2008-02-27 22:50) [41]

> Jeer  (27.02.2008 17:53:38)  [38]

Не уловимый Джо.
Кроме того меры приняты, и не за счет выкидывания МАС, а за счет шифрования.


 
Иксик ©   (2008-02-27 23:37) [42]


> Jeer ©   (27.02.08 15:48) [32]
>
>
> > Ega23 ©   (27.02.08 10:53)
>
>
> Я, вот, одного понять не могу - почему не понятен простой
> факт из комбинаторики ?
> "Число кортежей длины элементов n символов при алфавите
> объемом m символов конечно и составляет m^n"
>



> Jeer ©   (27.02.08 17:53) [38]
>
> Последний блок в GUID был прямо посвящен MAC.
> Т.е. был всегда одинаков для одного и того же интерфейса
> и, как бы, выдавал с головой компьютер, на котором он был
> создан.
>


Ну вот m и уменьшилось.


 
Petr V. Abramov ©   (2008-02-28 00:41) [43]

знание MAC-адреса есть большой удар по privacy личных данных. особенно  для пользователей популярных сайтов
:)


 
Denis__ ©   (2008-02-28 11:40) [44]

А как узнать MAC-адрес? Есть для этого функции в Делфе?


 
DVM ©   (2008-02-28 12:15) [45]


> Есть для этого функции в Делфе?

нет


 
Alex Konshin ©   (2008-02-28 12:21) [46]

Что-то вы много хотите в 16 байт запихнуть, уже чего только тут не упомянули. А подумать? Чтобы туда не запихнули всё равно всё сводится к 128 битам.
И не забывайте о законах Мерфи. Если что-то маловероятно, но теоретически может случиться, то оно обязательно случиться, причём так, что нанесёт наибольший возможный ущерб.

Я бы не стал забиваться на уникальность чего-то потенциально неуникального. Чего и вам желаю. Просто придумай алгоритм генерации гарантированно уникального значения, если уж ты не ограничен в ширине ключа (в разумных пределах). Вот елси бы тебе нужно было обязательно поместиться в 32 или 64 бита, тогда да, есть проблема, а так... Зачем без оглядки полагаться не нечто ненадёжное, которое теоретически может подвести, когда можно придумать надёжное?


 
Empleado ©   (2008-02-28 12:27) [47]


> DVM ©   (27.02.08 11:49) [14]
> GUID уникален статистически, как говорится. Т.е. повторения
> возможны, но настолько редко, что ими можно пренебречь.

Присоединяюсь


 
DVM ©   (2008-02-28 12:28) [48]


> Просто придумай алгоритм генерации гарантированно уникального
> значения

Такого алгоритма не бывает.


 
Jeer ©   (2008-02-28 14:18) [49]


> DVM ©   (28.02.08 12:28) [48]


Есть статистически уникальные значения и алгоритмы для их генерации:))


 
Иксик ©   (2008-02-28 17:06) [50]


> Jeer ©   (28.02.08 14:18) [49]
>
>
> > DVM ©   (28.02.08 12:28) [48]
>
>
> Есть статистически уникальные значения и алгоритмы для их
> генерации:))

Например GUID :))


 
@!!ex ©   (2008-02-28 20:34) [51]

> Такого алгоритма не бывает

При неограниченном ключе?
Бывает.
Пускай он состоит из трех частей.
В первой хранится текущее время вселенной с точностью до секунду
Во второй - текущий тик в текущей секунде(мы же знаем, сколько тиков дает проц, значит хнаем количество тиков в секунду)
В третьей - номер процессора(делаем счетчик, и каждому процессору присваиваем номер текущего счетчика, после чего счетчик инкрементируем)

Можно пример, когда такой ключ будет не уникальным?


 
DVM ©   (2008-02-28 20:57) [52]


> Можно пример, когда такой ключ будет не уникальным?

Можно. Тики и время запросто могут совпасть при генерации на разных компьютерах (по крайней мере ничего этому не мешает теоретически).

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

У процессора есть уникальный ID? Я знаю были попытки его ввести, вроде кончилось тем, что никому это не понравилось и затея умерла.
К тому же где гарантия, что в некий момент времени, некая компания "Вася Пупкин и Co" не станет выпускать свои совместимые процессоры совершенно игнорируя нумерацию Intel?


 
DVM ©   (2008-02-28 21:06) [53]


> @!!ex ©   (28.02.08 20:34) [51]

Подумай хорошенько, прежде чем поспешно утверждать, что уникальный ключ возможен.

Чтобы такой ключ сгенерировать, нужна некая глобально уникальная величина, от которой надо отталкиваться. Ее можно получить, либо присваивая каждому выпускаемому на планете компьютеру (процессору и т.д.) некоторого значения в порядке возрастания никогда не повторяясь (что малореально), либо из другой глобально уникальной величины. И т.д. получаем замкнутый круг.

Всякими хитрыми манипуляциями со временем и генераторами случайных чисел мы можем получить ключи, вероятность совпадения которых будет ничтожно мала, но не 100%. НО НЕТ ГАРАНТИИ, ЧТО ВОТ ЭТИ 0.000000000000000000000000000000000000001 процента не выпадут прямо сейчас.


 
Petr V. Abramov ©   (2008-02-28 22:35) [54]


> НО НЕТ ГАРАНТИИ, ЧТО ВОТ ЭТИ 0.000000000000000000000000000000000000001
> процента не выпадут прямо сейчас.

Законы Мэрфи имеют приоритет над законами больших чисел
electronically tested


 
Alex Konshin ©   (2008-02-29 09:57) [55]

> DVM ©   (28.02.08 20:57) [52]
> > Можно пример, когда такой ключ будет не уникальным?Можно.
>  Тики и время запросто могут совпасть при генерации на разных
> компьютерах (по крайней мере ничего этому не мешает теоретически).

Мы же решаем конкретную задачу? А тут, как я понял, дело происходит на одном компьютере. А в таком случае комбинации времени, номера процессора/ядра и performance counter будет более чем достаточно и, к тому же, меньше 128 бит.

Комбинация время/perfcounter решит проблему перевода времени назад. Номер ядра нужен, если дело происходит в мультитред программе или возможен запуск нескольких процессов.

Если же дело происходит на нескольких компьютерах в локальной сети, то достаточно добавить MAC адрес.


 
Иксик ©   (2008-02-29 16:33) [56]


> Alex Konshin ©   (29.02.08 09:57) [55]
>
> > DVM ©   (28.02.08 20:57) [52]
> > > Можно пример, когда такой ключ будет не уникальным?Можно.
>
> >  Тики и время запросто могут совпасть при генерации на
> разных
> > компьютерах (по крайней мере ничего этому не мешает теоретически).
>
>
> Мы же решаем конкретную задачу? А тут, как я понял, дело
> происходит на одном компьютере.



> Ega23 ©   (27.02.08 14:22) [29]
> Но тут система сильно распределённая получается.


 
Kolan ©   (2008-03-01 10:40) [57]

> Вот насколько уникален?

Генерируя 1 триллион ключей каждую наносекунду, перебрать все возможные значения удастся лишь за 10 миллиардов лет


 
Джо ©   (2008-03-01 16:01) [58]

> [57] Kolan ©   (01.03.08 10:40)
> > Вот насколько уникален?
>
> Генерируя 1 триллион ключей каждую наносекунду, перебрать
> все возможные значения удастся лишь за 10 миллиардов лет

Но это не значит, что ключи теоретически не будут повторяться, особенно, на разных машинах.


 
Alex Konshin ©   (2008-03-02 04:53) [59]

> Kolan ©   (01.03.08 10:40) [57]
> > Вот насколько уникален?Генерируя 1 триллион ключей каждую
> наносекунду, перебрать все возможные значения удастся лишь
> за 10 миллиардов лет

Вы путаете и подменяете слова генерировать и перебирать.
Перебор всех теоретически возможных ключей может быть и будет долгим. Но из этого совершенно не следует, что два (а ведь будет больше) таких генератора не выдадут одинаковые ключи в обозримое время. Это может случится и в первом десятке значений, а почему бы и нет?

Кстати, даже один генератор может выдавать одинаковые ключи гораздо чаще, чем вы думаете. Чтобы они не повторялись нужно принимать особые, нетривиальные меры. Почитайте хотя бы Кнута на досуге. Учиться никогда не поздно, может ещё не все потеряно.

Еще кстати, хотел бы заметить, что именно то обстоятельство, что при генерации UUID принимает участие так много разных данных, даёт мне основание утверждать, что UUID"ы повторяются намного порядков чаще, чем могло бы быть в идеальном случае для 128 битного числа. Так что в данном случае это скорее недостаток.


 
Alex Konshin ©   (2008-03-02 05:08) [60]

> Иксик ©   (29.02.08 16:33) [56]
Ega23 ©   (27.02.08 14:22) [29]> Но тут система сильно распределённая получается.

Ну и что? Если в данном конкретном случае можно как-то различать компьютеры (для локальных сетей, например, использовать MAC), то задача решена, не так ли? Пусть ключ 64+32+48+8 и длиннее 128 бит, но зато он гарантировано уникальный для этой конкретной задачи. При других условиях можно найти и гораздо более короткий ключ.


 
иксик ©   (2008-03-02 14:10) [61]


> Alex Konshin ©   (02.03.08 05:08) [60]
>
> > Иксик ©   (29.02.08 16:33) [56]
> Ega23 ©   (27.02.08 14:22) [29]> Но тут система сильно распределённая
> получается.
>
> Ну и что? Если в данном конкретном случае можно как-то различать
> компьютеры (для локальных сетей, например, использовать
> MAC)

Лично мне неизвестно, что можно... Может и можно, а может и нет. Если это заставы по периметру границы, ни в какую сеть не объединенные или еще что-нибудь подобное.


 
Denis__ ©   (2008-03-02 14:52) [62]


>
> > Есть для этого функции в Делфе?
>
> нет

А как всё-таки узнать МАС? Неужели никто не знает?


 
korneley ©   (2008-03-02 16:11) [63]


> Denis__ ©   (02.03.08 14:52) [62]

Я пользовал функцию
GetAdaptersInfo(...): DWORD; stdcall; external IPHelper;
Только надо учесть, что интерфейсов может быть больше, чем один.


 
korneley ©   (2008-03-02 16:27) [64]

Да, IPHelper = "IPHlpAPI.dll";


 
Denis__ ©   (2008-03-02 16:36) [65]


> korneley

Сэнкс



Страницы: 1 2 вся ветка

Форум: "Прочее";
Текущий архив: 2008.04.13;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.59 MB
Время: 0.008 c
11-1187243502
Александр-2006
2007-08-16 09:51
2008.04.13
Про KOLWord


15-1203709432
tesseract
2008-02-22 22:43
2008.04.13
MS сдаёться ?


2-1205872461
Blind Guardian
2008-03-18 23:34
2008.04.13
представление вещественного числа в памяти компьютара


15-1204078326
Fon
2008-02-27 05:12
2008.04.13
Google Summer of Code 2008


15-1203951929
Tirael
2008-02-25 18:05
2008.04.13
как получить document?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский