This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author veky
Recipients ned.deily, ronaldoussoren, terrygreeniaus, veky
Date 2020-08-14.12:18:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1597407535.61.0.194270531961.issue41552@roundup.psfhosted.org>
In-reply-to
Content
I'd like to point out that _even_ if you do reuse MAC address:

1. node IDs don't have to be derived from MAC addresses only (though in practice they usually are - I'm just saying the RFC gives you permission to include other information in it).

2. The time resolution is 100ns. As long as your UUID generations are more than 0.2μs apart, you're safe from collisions.

3. There is still a clock sequence, which for these purposes can be viewed as random. Even if you _do_ generate UUIDs on different machines with same MAC and naive nodeID-deriving algorithm, two or more of them within the same 100ns-interval, there is still only a probability of 1/16384 (62ppm) of collision.

In short, it's probably not a problem, though if there is an easy fix, of course it should be applied. Currently, there are two ways to indicate "this is not a real unique MAC address" that UUID recognizes: 

# Virtual interfaces, such as those provided by
# VPNs, do not have a colon-delimited MAC address
# as expected, but a 16-byte HWAddr separated by
# dashes. These should be ignored in favor of a
# real MAC address

and the 41st bit test /More details at #32107/. Maybe there is a third way, but if the above address doesn't play by these rules, maybe hardcoding it isn't so bad an idea.
History
Date User Action Args
2020-08-14 12:18:55vekysetrecipients: + veky, ronaldoussoren, ned.deily, terrygreeniaus
2020-08-14 12:18:55vekysetmessageid: <1597407535.61.0.194270531961.issue41552@roundup.psfhosted.org>
2020-08-14 12:18:55vekylinkissue41552 messages
2020-08-14 12:18:55vekycreate