active review Is a GUID (String Package)

[jgcode]

This OpenG Review is active.

Community,

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

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.viFetching info...

TEST - Is a GUID.viFetching info...

Code is in LabVIEW 2009

[MikaelH]

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

[jgcode]

  On 8/29/2011 at 1:33 AM, MikaelH said:

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

[jgcode]

I propose that we use RegEx and clean up the BD.

Not sure of the best way to handle the error, above is an example to maintain the VI's interface.

Code is in LabVIEW 2009

Is a GUID.viFetching info...

[jgcode]

  On 8/29/2011 at 1:33 AM, MikaelH said:

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:

Generate GUID:

Test GUID:

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

GUID.zipFetching info...

Code is in LabVIEW 2009

[jcarmody]

  On 8/29/2011 at 1:56 AM, jgcode said:

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.viFetching info...

guid3.txtFetching info...

[Phillip Brooks]

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

Maybe an OpenG wrapper VI to call this function?

[jgcode]

  On 8/29/2011 at 10:44 AM, Phillip Brooks said:

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.

[mje]

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.

[jgcode]

  On 8/29/2011 at 12:55 PM, mje said:

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:

Any others?

[mje]

This recommendation might be of interest. Specifically if a generation VI is created, all bits are not random (section 4.1).

[jgcode]

  On 8/29/2011 at 2:02 PM, mje said:

This recommendation might be of interest. Specifically if a generation VI is created, all bits are not random (section 4.1).

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

[asbo]

Another snippet to throw in the ring. It works on all the formats we've come up with so far.

I'll try to benchmark this (and the MD5 one) later if I have some time.

[mje]

  On 8/29/2011 at 2:25 PM, jgcode said:

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;

  Quote

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):

Also of note:

  Quote

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 August 29, 2011 by mje

[jcarmody]

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

[mje]

  On 8/30/2011 at 9:53 AM, jcarmody said:

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.zipFetching info...

[mje]

Urgh. I just realized the epoch on the RFC is 00:00:00.00, 15 Oct 1582. Please ignore the timestamp version of the GUID generator, it is not accurate until I fix the epoch (along with a precision bug).

[Jim Kring]

  On 8/29/2011 at 1:33 AM, MikaelH said:

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

  On 8/29/2011 at 1:56 AM, jgcode said:

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

[jgcode]

  On 9/3/2011 at 6:18 PM, Jim Kring said:

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).

[Jim Kring]

  On 9/7/2011 at 12:58 AM, jgcode said:

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)?

[mje]

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

GUID LV11.zipFetching info...

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

[jgcode]

  On 9/7/2011 at 1:17 AM, Jim Kring said:

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.

[Phillip Brooks]

Curious; just noticed a private method App.CreateGUID. (LV8.6)

Is this present on Mac as well?

Edited January 18, 2012 by Phillip Brooks

[jgcode]

  On 1/18/2012 at 6:33 PM, Phillip Brooks said:

Curious; just noticed a private method App.CreateGUID. (LV8.6)

Is this present on Mac as well?

(I haven't tried it but) - Shaun posted it here commenting that it can't be included in a build.

[Phillip Brooks]

Getting old, I posted in that thread but didn't remember it.

Where is the smiley with grey beard?