cancel
Showing results for 
Search instead for 
Did you mean: 

IPC and guid type

Kimmo_Linna
New Contributor II
Hi,

I have two different kind of TCP/IP clients and both are working very well for all other types than guid.

If I want to get 2 xexp 62 from q I’ll send the following bytes to q
1 1 0 0 23 0 0 0 10 0 9 0 0 0 50 32 120 101 120 112 32 54 50
1 1 0 0 23 0 0 0 10 0 9 0 0 0 50 32 120 101 120 112 32 54 50

And I’ll get the exactly the same response
1 2 0 0 17 0 0 0 247 0 0 0 0 0 0 208 67
1 2 0 0 17 0 0 0 247 0 0 0 0 0 0 208 67

If I want to get one guid (1?0Ng) from q I’ll send the following bytes to q
1 1 0 0 19 0 0 0 10 0 5 0 0 0 49 63 48 78 103
1 1 0 0 19 0 0 0 10 0 5 0 0 0 49 63 48 78 103

And I’ll get different responses
1 2 0 0 30 0 0 0 2 0 1 0 0 0 140 107 139 100 104 21 96 132 10 62 23 132 1 37 27 104
1 2 0 0 14 0 0 0 128 116 121 112 101 0

Could someone explain me why I can’t get the correct answer for guid with the other client? KDB+ answer is valid so It will get the correct input but why on earth I won’t get the correct answer. And why this is happening only for guid type? And it’s happening also if guid is in list, table and so on.

Best regards,

Kimmo

4 REPLIES 4

TerryLynch
New Contributor II
It's because 1?0Ng deals a random guid each time. It won't produce the same guid. 

q)value -9!"x"$1 1 0 0 19 0 0 0 10 0 5 0 0 0 49 63 48 78 103
,ddb87915-b672-2c32-a6cf-296061671e9d
q)value -9!"x"$1 1 0 0 19 0 0 0 10 0 5 0 0 0 49 63 48 78 103
,580d8c87-e557-0db1-3a19-cb3a44d623b1


If you wanted to guarantee the same guid you could (re)set the random seed each time you deal the guid:

q)"h"$-8!"system\"S 1\";1?0Ng"
1 0 0 0 31 0 0 0 10 0 17 0 0 0 115 121 115 116 101 109 34 83 32 49 34 59 49 63 48 78 103h


Then you'd get the same guid

q)value -9!"x"$1 0 0 0 31 0 0 0 10 0 17 0 0 0 115 121 115 116 101 109 34 83 32 49 34 59 49 63 48 78 103h
,46da7bb5-0a68-f6ae-137b-458983c4ff7f
q)value -9!"x"$1 0 0 0 31 0 0 0 10 0 17 0 0 0 115 121 115 116 101 109 34 83 32 49 34 59 49 63 48 78 103h
,46da7bb5-0a68-f6ae-137b-458983c4ff7f


Or alternatively generate the guid using a fixed 16 bytes with either 0x0 sv or "G"$

q)0x0 sv 0x409031f3b19c6770ee846e9369c98697
409031f3-b19c-6770-ee84-6e9369c98697
q)"G"$"409031f3-b19c-6770-ee84-6e9369c98697"
409031f3-b19c-6770-ee84-6e9369c98697


Terry


Hi Terry,

 

I know that. The problem is that the other response is an error message and the other one is a proper response.

 

If you responses

1 2 0 0 30 0 0 0 2 0 1 0 0 0 140 107 139 100 104 21 96 132 10 62 23 132 1 37 27 104

1 2 0 0 14 0 0 0 128 116 121 112 101 0

 

The ninth element is 2 in a proper answer and 128 in error message.

 

Best regards,

 

Kimmo

 

--

Kimmo Linna
Nihtisalontie 3 as 1

02630  ESPOO

kimmo.linna@gmail.com
+358 40 590 1074

 

Lähettäjä: Terry Lynch
Lähetetty: keskiviikko 9. joulukuuta 2020 11.47
Vastaanottaja: Kdb+ Personal Developers
Aihe: Re: [personal kdb+] IPC and guid type

 

It's because 1?0Ng deals a random guid each time. It won't produce the same guid. 

 

q)value -9!"x"$1 1 0 0 19 0 0 0 10 0 5 0 0 0 49 63 48 78 103
,ddb87915-b672-2c32-a6cf-296061671e9d
q)value -9!"x"$1 1 0 0 19 0 0 0 10 0 5 0 0 0 49 63 48 78 103
,580d8c87-e557-0db1-3a19-cb3a44d623b1

 

If you wanted to guarantee the same guid you could (re)set the random seed each time you deal the guid:

 

q)"h"$-8!"system\"S 1\";1?0Ng"
1 0 0 0 31 0 0 0 10 0 17 0 0 0 115 121 115 116 101 109 34 83 32 49 34 59 49 63 48 78 103h

 

Then you'd get the same guid

 

q)value -9!"x"$1 0 0 0 31 0 0 0 10 0 17 0 0 0 115 121 115 116 101 109 34 83 32 49 34 59 49 63 48 78 103h
,46da7bb5-0a68-f6ae-137b-458983c4ff7f
q)value -9!"x"$1 0 0 0 31 0 0 0 10 0 17 0 0 0 115 121 115 116 101 109 34 83 32 49 34 59 49 63 48 78 103h
,46da7bb5-0a68-f6ae-137b-458983c4ff7f

 

Or alternatively generate the guid using a fixed 16 bytes with either 0x0 sv or "G"$

 

q)0x0 sv 0x409031f3b19c6770ee846e9369c98697
409031f3-b19c-6770-ee84-6e9369c98697

q)"G"$"409031f3-b19c-6770-ee84-6e9369c98697"
409031f3-b19c-6770-ee84-6e9369c98697

 

Terry

 

 

On Wed, Dec 9, 2020 at 2:44 AM Kimmo Linna <kimmo.linna@gmail.com> wrote:

Hi,

 

I have two different kind of TCP/IP clients and both are working very well for all other types than guid.

 

If I want to get 2 xexp 62 from q I’ll send the following bytes to q

1 1 0 0 23 0 0 0 10 0 9 0 0 0 50 32 120 101 120 112 32 54 50

1 1 0 0 23 0 0 0 10 0 9 0 0 0 50 32 120 101 120 112 32 54 50

 

And I’ll get the exactly the same response

1 2 0 0 17 0 0 0 247 0 0 0 0 0 0 208 67

1 2 0 0 17 0 0 0 247 0 0 0 0 0 0 208 67

 

If I want to get one guid (1?0Ng) from q I’ll send the following bytes to q

1 1 0 0 19 0 0 0 10 0 5 0 0 0 49 63 48 78 103

1 1 0 0 19 0 0 0 10 0 5 0 0 0 49 63 48 78 103

 

And I’ll get different responses

1 2 0 0 30 0 0 0 2 0 1 0 0 0 140 107 139 100 104 21 96 132 10 62 23 132 1 37 27 104

1 2 0 0 14 0 0 0 128 116 121 112 101 0

 

Could someone explain me why I can’t get the correct answer for guid with the other client? KDB+ answer is valid so It will get the correct input but why on earth I won’t get the correct answer. And why this is happening only for guid type? And it’s happening also if guid is in list, table and so on.

 

Best regards,

 

Kimmo

 

--
You received this message because you are subscribed to the Google Groups "Kdb+ Personal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to personal-kdbplus+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/personal-kdbplus/b33afd7e-1ba3-44bf-947c-d29d5bb65c82n%40googlegro....

--
You received this message because you are subscribed to the Google Groups "Kdb+ Personal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to personal-kdbplus+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/personal-kdbplus/CA%2Bub6eF_kaqmVWpvyVLTBttRDvsscZhpaO9TTD%2BVPoMS....

 

Hi Kimmo,

The difference in your responses is indeed due to an error. The '128' is a type error due to guid not being supported on that connection. This can be corrected by sending a '3' as the compatibility byte in the connection handshake, which should enable guid on the connection. You can read more about it here,

Hope this helps!
-Eoin 

Hi Eoin,

Thank you very much. My other code was sending compatibility byte accidentally because I used U+0003 as end of text. 

Best regards,

Kimmo

keskiviikko 9. joulukuuta 2020 klo 13.43.06 UTC+2 eoin.m...@aquaq.co.uk kirjoitti:
Hi Kimmo,

The difference in your responses is indeed due to an error. The '128' is a type error due to guid not being supported on that connection. This can be corrected by sending a '3' as the compatibility byte in the connection handshake, which should enable guid on the connection. You can read more about it here,

Hope this helps!
-Eoin