IPC and guid type

Community Support
1

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

2

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

3

Hi Terry,

<o:p> </o:p>

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

<o:p> </o:p>

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<o:p></o:p>

1 2 0 0 14 0 0 0 128 116 121 112 101 0<o:p></o:p>

<o:p> </o:p>

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

<o:p> </o:p>

Best regards,<o:p></o:p>

<o:p> </o:p>

Kimmo<o:p></o:p>

<o:p> </o:p>

– <o:p></o:p>

Kimmo Linna
Nihtisalontie 3 as 1<o:p></o:p>

02630  ESPOO<o:p></o:p>

kimmo.linna@gmail.com
+358 40 590 1074<o:p></o:p>

<o:p> </o:p>

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

<o:p> </o:p>

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

<o:p> </o:p>

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

<o:p> </o:p>

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

<o:p> </o:p>

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

<o:p> </o:p>

Then you’d get the same guid

<o:p> </o:p>

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

<o:p> </o:p>

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

<o:p> </o:p>

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

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

<o:p> </o:p>

Terry

<o:p> </o:p>

<o:p> </o:p>

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

Hi,

<o:p> </o:p>

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

<o:p> </o:p>

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

<o:p> </o:p>

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

<o:p> </o:p>

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

<o:p> </o:p>

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

<o:p> </o:p>

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.

<o:p> </o:p>

Best regards,

<o:p> </o:p>

Kimmo

<o:p> </o:p>

–
Submitted via Google Groups

4

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,

https://code.kx.com/q/basics/ipc/#handshake

Hope this helps!
-Eoin 

5

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,

https://code.kx.com/q/basics/ipc/#handshake

Hope this helps!
-Eoin