No response to Verify_NodeID_Number_Global in branch.

[Poikilos]

Caused by WIP pull request #67
:edit: It is not yet clear whether a response to this request is expected from the CS-105.

Expected output:

Using settings:
{
  "device": "/dev/cu.usbmodemCC570001B1",
  "farNodeID": "09.00.99.03.00.0f",
  "farNodeID_comment": "serialized hardware node: for example, 02.01.57.00.04.9C and 09.00.99.03.00.35 are bobjacobsen's",
  "host": "tcs-cs-000f.local",
  "localNodeID": "05.01.01.01.03.01",
  "localNodeID_comment": "Warning: *only for openlcb*: 05.01.01.01.03.01 is reserved by OpenLCB Python examples. Find or suggest your organization's range at https://registry.openlcb.org/uniqueidranges and serialize if producing hardware (See LCC Standard(s)).",
  "port": 12021,
  "timeout": 0.5,
  "trace": false
}
RR, SR are raw socket interface receive and send;  RM, SM are message interface
      SL : link up
RM: Message (Link_Layer_Up) from 00.00.00.00.00.00
SM: Message (Verify_NodeID_Number_Global)
      SR: bytearray(b'\x80\x00\x00\x00\x14\x00\x00\x00\x00\x00d\x01\x96\xfeS\xd7\x90\x04\x90\x05\x01\x01\x01\x03\x01')

Actual output ends at "SM: Message (Verify_NodeID_Number_Global)".

:edit: I added 71544c8 to assert that the data is sent and also made it verbose (I changed it to "SENT" for clarity):

Sending Message: Message (Verify_NodeID_Number_Global)...
- SENT data (realtime raw): bytearray(b'\x80\x00\x00\x00\x14\x00\x00\x00\x00\x00d\x01\x96\xffN\xe8\xe6\x04\x90\x05\x01\x01\x01\x03\x01')

so now output matches (See #70 (comment))

[Poikilos]

@atanisoft On second thought, this issue is not valid, probably. "SR" above means sent remote, not responded. So the result of the #67 changes does not affect the outcome. This can probably be closed, but I'll keep it open in case we find a node that is supposed to respond or we fix the example.

(See #71 for the other issue with the PR)

[atanisoft]

#71 may also be valid unless the node itself (the example in this case) is also retrieving SNIP for the target nodes beyond just the simple ID. Normally train nodes will only respond that they exist for a given ID and that is all, it is then up to the node to retrieve SNIP for the remote node if needed.

I'll still collect data to confirm but I doubt it changes anything either way.

[Poikilos]

I can say for sure the SNIP data is not blank on the main branch, but is blank on the PR #67 branch.

[atanisoft]

Ok, yeah that would then likely be a bug of some form.

[Poikilos]

If you try to change anything, don't forget to pull again as I made a commit to validate my findings and it affects other files beyond this.

[Poikilos]

So, example_tcp_message_interface.py constructs the same message:

message = Message(MTI.Verify_NodeID_Number_Global,
                  NodeID(settings['localNodeID']), None)

but sends it in GridConnect form rather than binary, and does get a response.

I think we need more clarity on how and in what contexts TcpLink is supposted to work, and whether it is a complete implementation.