data types in rpc call from a node

[korda]

I have been trying to pass more then one parameter back from a remote node to Gateway/Client app. This is only works with integer numbers.
If you try to send something like this below, never reaches the client app, but works inside Portal Pro just fine.

def tellGateway():
line = '\x07\x5B\xCD\x15' # tried different types of brackets, same result
station = 54321#"\x00\xBC\x61\x4e"
rpc('\x00\x00\x01', 'myTest', line, station)
print line # this works in portal, prints funny characters fine


Why this code does not work in Gateway/Client?
Note: Client expects (int line, int station) in myTest

[kbanks]

I have been trying to pass more then one parameter back from a remote node to Gateway/Client app. This is only works with integer numbers.
If you try to send something like this below, never reaches the client app, but works inside Portal Pro just fine.

def tellGateway():
line = '\x07\x5B\xCD\x15' # tried different types of brackets, same result
station = 54321#"\x00\xBC\x61\x4e"
rpc('\x00\x00\x01', 'myTest', line, station)
print line # this works in portal, prints funny characters fine

Why this code does not work in Gateway/Client?
Note: Client expects (int line, int station) in myTest

Mark tried to explain your question to me before he had to take off for several days, so the following is somewhat paraphrased. As I understood him, there are two issues:

1) You are trying to pass the wrong type of parameters.

You say your C# client expects (int line, int station), but in your Python code variables line and station have quotation marks around them (making them strings, not ints).

2) Even after you fix this, there is some sort of issue around strings containing non-printable characters. We will have to get more details on this when Mark gets back. I don't know if this is an inherent problem with XLMRPC calls, or is something that will be addressed by a Gateway change.

[korda]

I understand there is a data type casting going on somewhere between Node and Gateway, but where and how I have know idea.
I think this would be nice to have a cross table fo data types on PC (C#) and RFE(PY).
Mark told me that PC's int corresponds to a "string". But the term "string" he did not explain. Is it Ascii string (null terminated) or Byte array, which does not have termination. On the top of that Node's script does not work with arrays. So this is my question again - what data types match?

[kbanks]

SNAPpy only has booleans (True/False), 16-bit ints (-32768 to 32767), and strings.

SNAPpy strings are not null-terminated (for example, "\x00\x00\x00" is a valid three-character SNAPpy string), but they are not byte arrays either.

Internally, SNAPpy keeps a separate length byte, in addition to the actual characters.

"desktop" Python supports multiple data types, refer to the standard Python docs.

[kbanks]

Mark told me that PC's int corresponds to a "string".

What we meant was that since a PC int is too big to send directly to SNAPpy, you will need to make a string out of it (from 123 to "123"), and send the string instead.

This is not something automatic, this is something you will have to do in your C# code anytime you are using data types that SNAPpy does not support.