Действительно ли коллизии GUID возможны?

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

, Когда я работал в Университете штата Иллинойс, у нас было два рабочих стола Dell, заказанные в разное время. Мы помещаем первый на сеть, но когда мы пытались поместить второй на сеть, мы начали получать сумасшедшие ошибки. После большого поиска и устранения неисправностей было определено, что обе машины производили тот же GUID (я не уверен точно, что для, но это сделало их обоих неприменимыми в сети). Dell на самом деле заменила обе машины в качестве дефектных.

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

Невозможный, если у пользователей есть различные машины с сетевыми платами, и даже если не это - все еще чрезвычайно крайний почти теоретический риск.

Лично я посмотрел бы в другом месте, поскольку это более вероятно ошибка, а не столкновение GUID...

Обеспечение, конечно, этого Вы не прерываете биты от GUID для создания его короче.

Конечно, его возможное.... Вероятный? Вряд ли, но это возможно.

Помнят, та же машина генерирует каждый GUID (сервер), так большая "случайность", которая основана на машине, определенная информация потеряна.

Только для усмешек, попробуйте следующий сценарий... (работы над SQL, 2005, не уверенный приблизительно в 2000)

declare @table table
(
    column1 uniqueidentifier default (newid()),
    column2 int,
    column3 datetime default (getdate())
)

declare @counter int

set @counter = 1

while @counter <= 10000
begin
    insert into @table (column2) values (@counter)
    set @counter = @counter + 1
end

select * from @table

select * from @table t1 join @table t2 on t1.column1 = t2.column1 and t1.column2 != t2.column2

Выполнение этого неоднократно (берет меньше, чем секунда), производит довольно широкий спектр из первого выбора, даже с ЧРЕЗВЫЧАЙНО кратковременным разрывом. До сих пор второй выбор ничего не произвел.

Мог код, используемый для генерации GUID, имеет ошибку в нем? Да, конечно, это могло. Но ответ совпадает с ним, был бы для ошибки компилятора - Ваш собственный код является порядками величины более вероятно, чтобы быть багги, так выглядите там первыми.

Две машины Win95, которые имеют платы Ethernet с дублирующимися MAC-адресами, выпустят дублирующиеся ГУИДЫ при плотно управляемых условиях, особенно если, например, питание уйдет в здании и них обоих начальная загрузка в точно то же время.

Посмотрите Википедию статья Globally Unique Identifier . Существует несколько способов генерировать GUID. По-видимому, старый (?) путь использовал Мак адрес, метка времени вниз к очень короткой единице и уникальному счетчику (для управления быстрыми поколениями на том же компьютере), таким образом заставляя их копировать почти невозможна. Но эти GUID были отброшены, потому что они могли использоваться для разыскивания пользователей...

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

Теперь, GUID тщательно разработаны, чтобы быть, по имени, глобально уникальными, таким образом, я рискну им, невозможно, или очень очень очень низкой вероятности. Я посмотрел бы в другом месте.

Я рассмотрел бы бритва Оккама как хорошее руководство в этом случае. Невероятно маловероятно, что у Вас есть коллизия GUID. Намного более вероятно, что у Вас есть ошибка или кто-то смешивающий с Вашими данными.

Возможности двух случайных столкновений GUID (~1 в 10^38) ниже, чем шанс не обнаружения поврежденного пакета TCP/IP (~1 в 10^10). http://wwwse.inf.tu-dresden.de/data/courses/SE1/SE1-2004-lec12.pdf , страница 11. Это также верно для дисководов, CD-приводов, и т.д.

, GUID статистически уникальны, и данные, которые Вы считываете с дб, только статистически корректны.

Сначала позволяет взгляду на шанс коллизии двух GUID. Это не, как другие ответы указали, 1 в 2^128 (10^38) из-за парадокс дня рождения , что означает, что для 50%-го шанса двух GUID, сталкивающихся, вероятность на самом деле 1 в 2^64 (10^19), который намного меньше. Однако это - все еще очень большое количество, и как таковой, вероятность коллизии, принимающей Вас, использует разумное количество GUID, является низким.

Примечание также, что GUID не содержат метку времени или MAC-адрес, поскольку многие люди также, кажется, верят. Это было верно для v1 GUID, но теперь v4 GUID используются, которые являются просто псевдослучайным числом , что означает, что возможность коллизии возможно выше, потому что они больше не уникальны для времени и машины.

Поэтому по существу ответ да, коллизии возможны. Но они очень маловероятны.

Редактирование: зафиксированный для высказывания 2^64

Они теоретически возможны, но с 3.4E38 возможные числа при создании десятков триллионов GUID через год шанс наличия одного дубликата 0.00000000006 ( Источник ).

, Если бы два пользователя закончили с тем же GUID, я держал бы пари, что существует ошибка в программе, которая заставляет данные быть скопированными или совместно использованными.

В основном они не возможны! , возможности астрономически низко .

, Но... Я - единственный человек I мир, о котором я знаю, это имело коллизию GUID однажды (да!).

И я уверен в нем, и что это не была ошибка.

то, Как это происходило в небольшом приложении, которое работало на Pocket PC, в конце операции команда, которая имеет сгенерированный GUID, должно быть выпущено. Команда после того, как это выполнялось на сервере, это было сохранено в таблице команды на сервере наряду с датой выполнения. Однажды, когда я отлаживал, я дал команду модуля (с недавно сгенерированным присоединенным GUID), и ничего не произошло. Я сделал это снова (с тем же гуидом, потому что гуид был сгенерирован только однажды в начале операции), и снова, и ничто, наконец пытаясь узнать, почему команда не выполняется, я проверил таблицу команды и тот же GUID, как текущий был вставлен 3 недели назад. Не веря этому, я восстановил базу данных от резервного копирования 2 недель, и гуид был там. Проверенный код, новый гуид был недавно сгенерирован несомненно об этом. Коллизия гуида головы, произошел только однажды, но я действительно желаю, чтобы я победил бы в лото вместо этого, шанс больше:).

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