Jump to content

Is a GUID (String Package)


jgcode

Recommended Posts

This OpenG Review is active.

Community,

This VI was in the Candidates folder for the String Package.

post-10325-0-77988500-1314577011.png

It has been sitting in there for a while therefore, I have just gone ahead and posted as is (so the license will be migrated on confirmation from the author etc...).

What are you thoughts on this VI?

  • Would you like to see such a function in OpenG?
  • Can you optimize the code?
  • It may be better suited in e.g. Comparison Package?
  • Should it be rejected?

Kind regards

Jonathon Green

OpenG Developer

Is a GUID.vi

TEST - Is a GUID.vi

Code is in LabVIEW 2009

Link to comment

If there is a VI that creates a GUID, it's a good thing to have.

So is there a VI that will do this in string package?

//Mike

Thanks for you reply Mike,

If that is VI that you would like too see (currently does not exist) in OpenG then we can definitely look at this?

Community, please comment on the addition of such a VI to OpenG as well in this thread (in relation to the attached VI).

Cheers

-JG

Link to comment

If there is a VI that creates a GUID, it's a good thing to have.

Attached are some prototype VIs to add such functionality to the String Package if people would care to comment.

Generate Random ASCII Alphanumeric Characters:

post-10325-0-81006300-1314609715_thumb.p

Generate GUID:

post-10325-0-61930500-1314609717.png

Test GUID:

post-10325-0-75254100-1314609825.png

Additionally there is a Generate Random ASCII Printable Characters functions included as well the the support VI for generating the lookup tables etc.

GUID.zip

Code is in LabVIEW 2009

Link to comment

Thanks for you reply Mike,

If that is VI that you would like too see (currently does not exist) in OpenG then we can definitely look at this?

Community, please comment on the addition of such a VI to OpenG as well in this thread (in relation to the attached VI).

Cheers

-JG

I've needed one and have seen requests before. I've done some crazy things in my quest...

The .txt file is the VB Script (was .vbs) called in the VI (hidden in Diagram Disable structure).

Generate GUID.vi

guid3.txt

post-7534-0-12322400-1314611709_thumb.pn

Link to comment

There is a function in LabVIEW to generate a GUID. See this post.

http://lavag.org/top...dpost__p__32909

Maybe an OpenG wrapper VI to call this function?

I don't know if I want to be using VI's in the resources folder?

(It's not because of linking etc... we can handle that dynamically).

I am pretty sure we could come up with our own.

Link to comment

I'd argue the function is too restrictive. About the only thing that can be said about GUIDs is they are 128 bit hex strings. Formatting of a GUID is not always enforced.

Personally, I would use a regex more along the lines of

^\{?\w{8}-?\w{4}-?\w{4}-?\w{4}-?\w{12}\}?$

Even then, some common forms of GUIDs would still return false:

(CA761232-ED42-11CE-BACD-00AA0057B223)

{0xCA761232, 0xED42, 0x11CE, {0xBA, 0xCD, 0x00, 0xAA, 0x00, 0x57, 0xB2, 0x23}}

I've never seen the one top one in use, but I've used the bottom one plenty of times before as it also turns out to be a valid C statement.

The difficult thing is there is no standard to interpret. I'd recommend adding a VI to create a GUID, and then have Is a GUID.vi follow whatever format is used in the create function, while also being able to interpret whatever format(s) LabVIEW might present.

  • Like 1
Link to comment
I'd recommend adding a VI to create a GUID, and then have Is a GUID.vi follow whatever format is used in the create function, while also being able to interpret whatever format(s) LabVIEW might present.

I know there is this format related to the Project:

post-10325-0-37071100-1314623821.png

Any others?

Link to comment

Just from quickly browsing the doc, is that was jcarmody has done (or similar) in his screenshot?

I don't believe so. By my reading, a pseudo-random GUID conforming VI would follow the logic in section 4.4. Given the following syntax:

 typedef struct {    unsigned32  time_low;    unsigned16  time_mid;    unsigned16  time_hi_and_version;    unsigned8   clock_seq_hi_and_reserved;    unsigned8   clock_seq_low;    byte        node[6];} uuid_t;

4.4. Algorithms for Creating a UUID from Truly Random or Pseudo-Random Numbers

The version 4 UUID is meant for generating UUIDs from truly-random or pseudo-random numbers.

The algorithm is as follows:

  • Set the two most significant bits (bits 6 and 7) of the clock_seq_hi_and_reserved to zero and one, respectively.
  • Set the four most significant bits (bits 12 through 15) of the time_hi_and_version field to the 4-bit version number from Section 4.1.3.
  • Set all the other bits to randomly (or pseudo-randomly) chosen values.

So something like this (all optimization aside):

post-11742-0-80790900-1314645714.png

Also of note:

Validation mechanism:

Apart from determining whether the timestamp portion of the UUID is in the future and therefore not yet assignable, there is no mechanism for determining whether a UUID is 'valid'.

Edited by mje
  • Like 1
Link to comment

LabVIEW is so not self-documenting. I know I had a reason for using the time and IP address in my VI.

There is precident in the document. Version 1 of the GUID uses a timestamp to help reduce the probability of collisions. In this case though, the prospect of a "valid" GUID comes up, in that it can never contain a timestamp in the future. This version though typically uses the 48-bit MAC address, not the IP.

I've updated the VI I wrote to generate GUIDs. It now supports version 1 (timestamp) and version 4 (random). I'll look into adding support for version 3 (MD5) on the weekend if there's interest. Maybe even version 5 (SHA-1), though I don't think we have access to a platform neutral SHA-1 algorithm in LabVIEW?

Also note in the version 1 implementation, I created a multicast MAC address out of thin air. I don't believe there's a cross-platform way of getting the MAC from LabVIEW, correct? Regardless by setting the address to multicast, the random number should never collide with a real NIC's MAC as the RFC recommends.

The files are now in a zip because in addition to Create GUID.vi, there's also a new VI to create properly resolved timestamps, and a GUID typedef.

I also apologize for for derailing this review. I just think that if you're going to have an Is GUID.vi, it should be consistent with whatever means you have of generating said GUID since there is no standard adopted for formatting.

I'll also pose the question of do we want the Is GUID.vi to validate version 1 GUIDs, insomuch as it would return false if the timestamp is in the future?

GUID LV9.zip

  • Like 1
Link to comment

If there is a VI that creates a GUID, it's a good thing to have.

So is there a VI that will do this in string package?

//Mike

If that is VI that you would like too see (currently does not exist) in OpenG then we can definitely look at this?

Community, please comment on the addition of such a VI to OpenG as well in this thread (in relation to the attached VI).

Cheers

-JG

I'm really in favor of creating OpenG functions for Create GUID and Is a GUID. Enrique Vargas contributed the MD5 code to OpenG, which was part of the CryptoG library -- I know that there's a function in there for creating a GUID with a pseudo-random generator via SHA functions.

-Jim

  • Like 1
Link to comment
I'm really in favor of creating OpenG functions for Create GUID and Is a GUID. Enrique Vargas contributed the MD5 code to OpenG, which was part of the CryptoG library -- I know that there's a function in there for creating a GUID with a pseudo-random generator via SHA functions. -Jim

I thought it couldn't hurt, so I have gone ahead and tried to ontact the author and see if the code could be donated to OpenG etc... (given that Library is no longer available and it was released as Open Source).

Link to comment

I thought it couldn't hurt, so I have gone ahead and tried to ontact the author and see if the code could be donated to OpenG etc... (given that Library is no longer available and it was released as Open Source).

Well, technically, it doesn't need to be "donated" to OpenG, it just needs to be released under a BSD license, so that OpenG can distribute it -- that's the (semantic) difference between ownership (copyright) and rights (license)? :)

Link to comment

For what it's worth, attached is a zip containing three Create GUID implementations consistent with IETF RFC-4122:

GUID LV11.zip

Version 1: Timestamp

Version 3: MD5

Version 4: Random

The V3 implementation requires the OpenG MD5 library. Also included is a VI that generates a 100 ns base timestamp (used in the V1 implementation, actually works as advertised now), along with a typedef that is used in the implementations.

There is no V5 VI, I haven't tracked down the SHA-1 library you have been talking about, but it should be trivial to modify the existing V3 VI (replace the checksum call with a SHA-1 and modify the version bitmask) if it doesn't already have the functionality you describe.

If there's interest in having the Is A GUID method perform a basic timestamp validation for V1 GUIDs, I can throw some code together.

-m

  • Like 1
Link to comment

Well, technically, it doesn't need to be "donated" to OpenG, it just needs to be released under a BSD license, so that OpenG can distribute it -- that's the (semantic) difference between ownership (copyright) and rights (license)? :)

Cool.

In the context of the email I sent, 'donated' referred to if OpenG would maintain the library (upgraded, fixes etc...), if e.g. the author preferred this.

Link to comment
  • 4 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.