Code mismatch between PacketClient (cpp project) and PythonClient (python project)

NatNet, VRPN, TrackD, and Plugins
Post Reply
JosephMatan
Posts: 8
Joined: Sun Jan 05, 2020 8:52 am

Code mismatch between PacketClient (cpp project) and PythonClient (python project)

Post by JosephMatan » Thu Jan 09, 2020 5:53 am

Hi,

Since my client runs on a linux machine, I'm working with the PythonClient sample as a starting point.
I've notice that if I run the <PythonSample.py> as is, no data is received.
However if I'm adding to the run() function a NAT_PING command, then the server start streaming data continuously (forever).

First, it seems very strange that this is what a NAT_PING command does...
Later, I took a look at the PacketClient sample (cpp project) and there I saw that the NATNET message ids doesn't include NAT_PING, but instead it has a NAT_CONNECT command (which is now make sense why the NAT_PING command did something that causes the server to stream...).

Moreover, regarding the following definition (in the python sample):
NAT_PING = 0 // also known as NAT_CONNECT at the cpp sample
NAT_PINGRESPONSE = 1 // also known as NAT_SERVERINFO at the cpp sample
NAT_REQUEST = 2
NAT_RESPONSE = 3
NAT_REQUEST_MODELDEF = 4
NAT_MODELDEF = 5
NAT_REQUEST_FRAMEOFDATA = 6"
NAT_FRAMEOFDATA = 7
NAT_MESSAGESTRING = 8
NAT_DISCONNECT = 9
NAT_UNRECOGNIZED_REQUEST = 100
I've notice that the only messages that I'm getting a valid response from, are NAT_PING/NAT_CONNECT and NAT_REQUEST_MODELDEF.
The other commands are failing when trying to parse the response, or I'm getting an error of "received unrecognized request from server".

Is there something more updated (a code or a document) to learn and understand the protocol ?
After sending the NAT_PING/NAT_CONNECT command, the data start streaming. That's a great start. Is there a command that can stop the streaming ?

Even only a partial answer will be much appreciated,
Thanks,
Joseph

jgreenberg
Posts: 2
Joined: Thu Jan 09, 2020 5:11 pm

Re: Code mismatch between PacketClient (cpp project) and PythonClient (python project)

Post by jgreenberg » Thu Jan 09, 2020 5:24 pm

I have been trying to figure out the same thing. The python client runs fine for me on a windows machine, but the exact same code (only modifying the localIP) only seems to receive the rigidbody descriptor.
Thanks to your post, I added a line to the end of NatNetClient.py to call the ping command:
self.sendCommand( self.NAT_PING, "", self.commandSocket, (self.serverIPAddress, self.commandPort) )

Alone, that didn't work, but changing the streaming transmission type from Multicast to Unicast got data to show up!
This is not ideal, as I want to stream to multiple devices, but at least it might help figure out why this doesn't work.

JosephMatan
Posts: 8
Joined: Sun Jan 05, 2020 8:52 am

Re: Code mismatch between PacketClient (cpp project) and PythonClient (python project)

Post by JosephMatan » Sun Jan 12, 2020 1:46 am

You are definitely right! And thanks got sharing!
Changing the streaming transmission type from Multicast to Unicast got data to show up (I just forgot add this important fact to my last post).
I have no idea why it's like that - I hope we get an official answer for that. I guess It's a bug.

jgreenberg
Posts: 2
Joined: Thu Jan 09, 2020 5:11 pm

Re: Code mismatch between PacketClient (cpp project) and PythonClient (python project)

Post by jgreenberg » Mon Jan 13, 2020 6:22 pm

I left out a crucial part...
The python client runs fine for me on a windows machine, but the exact same code RUN ON A RASPBERRY PI (linux) only seems to receive the rigidbody descriptor. Just curious if you are also running the python client on linux. I'm wondering if the multicast option is a linux thing.

JosephMatan
Posts: 8
Joined: Sun Jan 05, 2020 8:52 am

Re: Code mismatch between PacketClient (cpp project) and PythonClient (python project)

Post by JosephMatan » Tue Jan 21, 2020 8:04 am

Yes, I'm running in a linux machine (mentioned it at the beginning of the post).
I've no idea if the multicast issue is a bug or perhaps an incorrect configuration...

Post Reply