> > > hi nochmal... > > > > Wie du oben siehst ist das auch auf l�ngeren Zeitraum > ausgeschlossen. > > dem stimme ich nicht ganz zu.. > deine rechnung ist fabelhaft, allerdings vergisst du einen > faktor, der den name "zufall" zu recht verdient hat..(und da > war dann auch noch murphy*g*) > > d.h. es kann heute sein, oder auch in 500 millionen jahren, > oder nie, dass die gleichen duis erzeugt werden.. ich rede ja > nicht von der wahrscheinlichkeit sondern von der m�glichkeit. > und die ist gegeben.
Welcher zufall? Vieles an der guid-berechnung ist nicht zuf�llig. Die MAC adresse ist mit drin, d.h. es kann schon mal nur innerhalb des selben rechners die gleiche GUID erzeugt werden. Das Datum ist auch mit drin, d.h. da das Jahr vierstellig ist kann es im prinzip nur alle 10000 Jahre die gleiche GUID erzeugt werden(achtung: das heisst nicht, dass es auch passiert)... Abgesehen davon das es dann zu anderen Problemen mit dem Datum kommt... > > > D.h. GUIDs sind 100% einmalig f�r den praktischen Einsatz, > nicht nur > > theoretisch... > > der satz schlie�t sich selbst aus.. theoretisch, praktisch.. > egal wie du es nennen magst. es ist nicht reell.. Ja, der satz ist schon ein bischen komisch.... > > > Was sie aber dar�ber hinaus noch einmaliger macht ist, das > GUIDs gar > > nicht global gesehen einmalig sein m�ssen(obwohl sie es > sind), sondern > > nur innerhalb einer Applikation... Was k�mmerts Dich das IBM > > ApplikationXYZ im Rechenzentrum USA gerade einem Kunden die gleiche > > GUID zugewiesen hat wie Du einer Datei deines CMS.... > > auch hier vergisst du eine komponente.. .nat�rlich will ich > was eindeutiges.. angenommen du programmierst ein kl. > steuerelement. und ich auch.. wir beide haben nun -der zufall > wollte es so*g*- die gleiche guid und den gleichen kunden. > was passiert also, wenn unser beider kunde unsere beiden > komponenten installiert.. auf einem rechner haben guids > nunmal eindeutig zu sein, und diese werden auf deinem system > bestimmt, nicht erst beim kunden.. Wir waren eigentlich bei Datenbanken... Und da ist es egal, ob ein Kunde zwei DBs hat, die von verschiedenen Applikationen verwendet werden und aber die gleichen GUIDs enthalten.... Was ich aber trotzdem f�r eigentlich ausgeschlossen halte... > > > > > letzter punkt ist eine berechnung eines schl�ssels, die eine > > > eindeutigkeit �ber alle grenzen hinweg unm�glich lassen > > > wird.. denn 1x2 ist leider immer noch das gleiche wie 2x1(im > > > gegensatz dazu w�re 12 nat�rlich nicht 21).. d.h selbst bei > > > unterschiedlichen zeiten, unterschiedlichen mac-adressen und > > > komplett anderer hardware kann es zum gleichen schl�ssel kommen.. > > > > Wie kommst du darauf, dass eine einfache multiplikation > gemacht wird? > > 16 bytes reichen locker f�r die komplette MAC, genaue > uhrzeit(genauer > > als auf die sekunde) und noch ein ein paar bytes sonst. > > Zufalls-infos... > > ich komme nicht darauf, dass eine "einfache" multiplikation > gemacht wird..so wollte ichs nicht darstellen.(wie kommst du > da drauf*g*) aber du wirst mir doch recht geben, dass 16bytes > begrenzt sind.. oder? wenn du jetzt sagst,.. "dass reicht > doch l�nger als es das universum gibt", dann erinnere ich > dich gerne an ein "ph�nomen" namens y2k-bug .. 2stellige > jahresangaben reichen ja auch l�nger, als es computer in > dieser form geben wird, war bestimmt eine denkansatz(und > zudem spielte eiserne sparsamkeit an jedem bit eine sehr > gro�e rolle).. also ewig... trotzdem, oder gerade deswegen > geb ich dir aber auch vollkommen recht. es reicht ewig... nur > damit ists noch lange nicht eindeutig. (mehr hab ich nicht, > und mehr wollte ich auch gar nicht darlegen) > Die Berechnung sollte zeigen wie gross eigentlich der GUID-Raum ist... Eindeutigkeit: siehe Zuf�lligkeit oben. Den y2k-Bug kann ich nicht als Argument z�hlen, da es nichts zur Sache tut. > und solange ich etwas "aus-/berechne", solange besteht eine > m�glichkeit durch unterschiedliche rechenwege zum gleichen > ergebnis zu kommen.. die macid und die uhrzeit und die > zufallbits werden nicht aneinandergeh�ngt, da dadurch > theoretisch (sp�testens im jahr 10000) eine verl�ngerte guid > zum tragen kommen w�rde.. imho ist es sogar so stark Nein, dann wird es ein y10k-Bug geben... Aktuelle systeme k�nnen kein yahr 10000 verarbeiten... D.h. GUIDs in dieser Form, bzw. mit aktuellen Algorithmen wird man sowieso nicht f�r ewig erzeugen k�nnen... > verwurschtelt und durch zufallbits verdreht, dass man > nichtmal zur�ckrechnen kann, wann die guid erstellt wurde. > (ich glaub das mal gelesen zu haben, bin aber nicht ganz sicher) Das heisst aber nichts... Wenn ich mit nem einfachen schl�ssel die GUID XORe, dann kannst Du auch nicht mehr auf die GUID zur�ckrechnen... Das sagt nichts �ber die Qualit�t der Ausnutzung des GUID-Raumes aus... > > nochmal. ich halte die guid f�r eindeutig genug. aber die > aussage, dass diese 100%ig und immer und ewig eindeutig ist, > ist schlicht und wenig ergreifend einfach falsch. sowas muss > man auch gar nicht verbissen sehen, wenn man bedenkt, dass > selbst 2 gleiche guids erst dann problematisch werden > k�nnen(nicht m�ssen), wenn diese auf einem rechner vorhanden > sind.. nichtmal dass reicht aus.. es m�sste sogar in der > gleichen tabelle oder �hnlichem (zb registry) gespeichert > sein, um endlich probleme verursachen zu k�nnen(auch dann > ists nicht immer schlimm). > Ich glaube das eigentliche Problem, das du hast ist, das du denkst: GUID ist nicht unendlich gross, sondern nur 128bit, also kann es nicht eindeutig sein... 1. Anhand meiner Berechnung hast Du gesehen, dass es genug GUIDs gibt, d.h. das erste Problem ist gel�st... 2.Problem: Wird auch keine GUID zweimal erzeugt? L�sung: - GUID enth�lt MAC. MAC ist eindeutig f�r einen Rechner/Netzwerkkarte -> GUID-Dubletten k�nnen wenn �berhaupt nur auf dem selben Rechner erzeugt werden. - GUID enth�lt die aktuelle Zeit. -> GUID-Dubletten k�nnen wenn �berhaupt nur zur selben Zeit erzeugt werden... - GUID enth�lt Zufall(und noch einige Komponenten) -> GUID-Dubletten k�nnen wenn �berhaupt nur erzeugt werden, wenn der Zufallsgenerator das selbe ausspuckt... Zusammengenommem kann gesagt werden das in den n�chsten paar tausend jahren bestimmt keine einzige GUID mehrfach erzeugt wird... Also eine Periode, die um einiges gr�sser ist als 30Jahre... Bei der Geschwindigkeit mit der heutige Entwicklungen passieren bin ich mir sicher, das wir in 300 Jahren keine Applikation von heute mehr laufen haben, auch wenn jetzt das y2k-Argument wieder kommt.... > nevermind .. wolfgang ;) Selber nevermind... Claudius ;-) | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
