TGUID - einzigartige ID auf andere Computer Systeme ?

[dummzeuch]

Zitat von stahli:

Oh, das stimmt.

SizeOf gibt 24 Byte an, bei TGuid nur 16.

Die einzelnen Werte sind ja aber korrekt:

Delphi-Quellcode:

  TmyGUID = record
      C  : Word;      //: 2 Byte 
      TS1: TDateTime; //: 8 Byte 
      TS2: TDateTime; //: 8 Byte 
Summe=18

Delphi-Quellcode:

  TGUID = record
    D1: Cardinal; //: 4 Byte
    D2: Word; //: 2 Byte
    D3: Word; //: 2 Byte
    D4: array[0..7] of Byte; //: 8 Byte
Summe=16

Wo ist da mein Denkfehler bzw. Wissenslücke?
TGuid ist ja auch kein gepackter Record oder so?

EDIT: Ok, mit "packed record" komme ich auf das erwartete Ergebnis.

Das Problem ist, dass das erste Feld in Deinem Record nur 2 Bytes groß ist. Das zweite Feld wird aber ohne Packed auf eine 8-Byte Grenze verschoben. Dadurch gibt es zwischen dem ersten und dem zweiten Feld eine Lücke von 6 Bytes. Mit Packed Record wird diese dann entfernt.

[Sinspin]

Ich würde auch auf TDateTime verzichten, das ist ein Gleitkommawert bei dem es zu unabsichtlicher Veränderung im Millisekundenbereich kommen kann.
Mikrosekunden als Int64 ab einem bestimmten Datum halte ich für deutlich einfacher zu handeln. Auch weil es ein Wert ist den Du so wie er ist vom System abfragen kannst.

UInt64 basiert, µs Qualität TimeCode via QueryPerformanCecounter oder 2*DWord, µs Qualität, FileTime format, UTC TimeStamp via GetSystemTimePreciseAsFileTime

[mytbo]

Als Ergänzung zum Post von Thomas (dummzeuch) hier der Link zur Hilfe (Record-Typen). Zur Veranschaulichung:

Delphi-Quellcode:

type
  TTestGuid = {packed} record
    c: Word;
    ts1: TDateTime;
    ts2: TDateTime;
  end;

const
  REC_SIZE = SizeOf(TTestGuid);
var
  guid: TTestGuid;
  p: array[0..REC_SIZE - 1] of Byte absolute guid;
begin
  FillChar(guid, REC_SIZE, 0);
  FillChar(guid.ts1, SizeOf(TDateTime), MaxByte);
  guid.c := MAXWORD;
  var s: String;
  for var i: Integer := Low(p) to High(p) do
    s := s + IfThen((p[i] <> 0), '#', '*');

  ShowMessage(Format('Size: %d: %s', [REC_SIZE, s])); // Size: 24: ##******########********

Bis bald...
Thomas

[himitsu]

Die Speicherausrichtung.
Nach den ersten 2 Byte, wird der nächste Typ an den nächsten geraden 8 Byte ausgerichtet, da er so groß ist.

[stahli]

Danke Euch.

@Sinspin
Eine Änderung des Zeitstempels (des Realwertes) sollte m.E. nur möglich sein, wenn man mit den Werten rechnet.

Ich
- ermittle jedoch den Wert nur einmalig,
- speichere ihn in die Variablen,
- übergebe ich an Methoden,
- schreibe in in einen Stream,
- wandle ihn in einen String um und zurück,
- und vergleiche die Werte auf Gleichheit.

Besteht auch in diesen Fällen die Gefahr einer Verfälschung?
Wenn nicht, würde ich lieber bei den Timestamps bleiben, da diese dann beim Debugging auch besser einzuordnen sind(gestern erzeugt oder letzten Monat).

Die Systemlaufzeit wäre gleich sicher aber weniger sprechend. Wenn in meinem Anwendungsfall tatsächlich die Gefahr einer Timestampverfälschung bestehen kann, dann würde ich aber tatsächlich lieber umstellen.

[mytbo]

Für alle, die es schon vermisst haben, mORMot hat dieses Angebot:

Zitat:

TSynUniqueIdentifierGenerator: thread-safe 64-bit integer unique identifier computation
- contain generation time
- they are increasing over time (so are much easier to store/shard/balance than UUID/GUID)
- each identifier would contain a 16-bit process identifier, which is supplied by the application
- identifiers may be obfuscated as hexadecimal text, using both encryption and digital signature

Hier etwas Quelltext:

Delphi-Quellcode:

uses
  mormot.core.base,
  mormot.core.unicode,
  mormot.crypt.secure;

var
  guid: Int64;
  guidStr: String;
  guidGen: TSynUniqueIdentifierGenerator;
begin
  guidGen := TSynUniqueIdentifierGenerator.Create({Identifier:}12345, {SharedObfuscationKey:}'TopSecret', 10); // create once in application
  try
    guid := guidGen.ComputeNew;
    ShowMessage(Format('Guid: %s', [guid.ToString]));

    guidStr := Utf8ToString(guidGen.ToObfuscated(guid));
    ShowMessage(Format('Guid obfuscated: %s', [guidStr]));

    var fromObfuscatedGuid: TSynUniqueIdentifier; // Int64
    if guidGen.FromObfuscated(StringToUtf8(guidStr), fromObfuscatedGuid) then
      ShowMessage(Format('Guid: %d, From obfuscated: %d', [guid, Int64(fromObfuscatedGuid)]));

    var guidBits: TSynUniqueIdentifierBits;
    guidBits.From(guid);
    ShowMessage(Format('DateTime created: %s', [DateTimeToStr(guidBits.CreateDateTime)]));

    ShowMessage(Format('JSON: %s', [Utf8ToString(guidBits.AsVariant._JSON)]));
  finally
    guidGen.Free;
  end;

Im Beispiel ist der Identifikator "12345". Es stehen 16-Bit zur Verfügung. Eine Möglichkeit wäre, jedem Kunden/Installation eine eigene zuzuweisen.

Die Ausgabe für das Beispiel ist:

Code:

Guid: 3647375681599078401
Guid obfuscated: 7dc1647a8d032aaeebe65dff209d32ff
Guid: 3647375681599078401, From obfuscated: 3647375681599078401
DateTime created: 27.10.2023 21:20:55
JSON: {"Created":"2023-10-27T21:20:55","Identifier":12345,"Counter":1,"Value":3647375681599078401,"Hex":"329E14DB981C8001"}

Bis bald...
Thomas

[Stevie]

Dieser Thread erinnert mich stark an https://xkcd.com/927/

[Sinspin]

Zitat von stahli:

Ich
- ermittle jedoch den Wert nur einmalig,
- speichere ihn in die Variablen,
- übergebe ich an Methoden,
- schreibe in in einen Stream,
- wandle ihn in einen String um und zurück,
- und vergleiche die Werte auf Gleichheit.

Besteht auch in diesen Fällen die Gefahr einer Verfälschung?

D11 System.Pas:
TDateTime = type Double; Ein Gleitkommazahlenwert ist intern als Bruch gespeichert, um so weiter Du hinter das Komma kommst um so ungenauer wird die Zahl.
Es hängt davon ab wie Du umwandelst. Also wieviele Stellen nach dem Komma mit erfasst werden um eine ausreichend genau zu sein.
Beim zurück wandeln von String in Gleitkomma ensteht intern mit hoher Wahrscheinlichkeit eine andere Zahl / anderer Bruch, wenn Du nicht sicherstellst das Du wieder eine ausreichende Anzahl von Nachkommastellen lieferst.

Vergleichen von Gleitkommazahlen ist wie Lose ziehen. Die Operationen finden zwar mit dem Wissen statt dass Gleitkommazahlen verglichen werden, aber 100% sicher ist das nicht.
Was klappt, aber langsam ist, wäre erst in Zeit-String-Representation umwandeln.

Generell macht es wenig Sinn sich mit Gleitkommazahlen rumzuquählen wenn es nicht unbedingt sein muss.
Deswegen wird in vielen OS darauf verzichtet. Warum Delphi sich den Schuss ins Knie geleistet hat und steif daran festhält erschließt sich mir nicht.

[paule32.jk]

Hallo,

auf welcher Basis ist denn der Delphi TDateTime ?
Wenn denn dann die Unix ist - also die bei 1970 anfängt...
... dann ist bei 2038 Sense im Gelände.

Ich weiß zwar nicht, ob ich an diesen Datum noch programmiere ... aber vielleicht ist das ja was interessantes für die jüngere Generation ...

[Delphi.Narium]

Suchmaschine meiner WahlTDateTime Delphi

Delphihilfe: System.TDateTime