TCPROS connection header probe attribute for discovery

Question

Dear ROS Supporters,

Is there developer documentation for TCPROS connection header probe attribute for discovery?

Thanks,

Aaron

I believe probe was used by rossrv for introspecting service type information that is not available via the XMLRPC API. This made me wonder what else is not documented. I've been working on a Java client for over a year, and this sort of information would of been like gold. My client did discovery of service types via an auto-generated shell script that is not platform independent, and required the user to manually run the script, then import the discovered data to the client.

This data trace was performed in February 2014 on the latest version of ROS.

The changelist at the following URL mentioned the probe... http://wiki.ros.org/ROS/ChangeList/1.2

The following is the Hex of a Wireshark data trace: 410000000e000000736572766963653d2f737061776e0700000070726f62653d311400000063616c6c657269643d2f726f7373657276696365080000006d643573756d3d2a The following is printable text of the above hex string: service=/spawn probe=1 callerid=/rosservice md5sum=*

---

Originally posted by unknown_entity1 on ROS Answers with karma: 104 on 2014-03-11

Post score: 1

Answer 1

You're probably interested in the Slave API and the TCPROS documentation

Update

I'm going to agree that this isn't documented in the TCPROS documentation.

I've found these references to the probe field in the ROS client libraries:

• https://github.com/ros/ros_comm/blob/indigo-devel/clients/roscpp/src/libros/service.cpp#L55
• https://github.com/ros/ros_comm/blob/indigo-devel/clients/rospy/src/rospy/impl/tcpros_service.py#L113-L115
• https://github.com/ros/ros_comm/blob/indigo-devel/clients/rospy/src/rospy/impl/tcpros_service.py#L645
• https://github.com/ros/roslisp/blob/master/src/tcpros.lisp

It looks like it's used in rospy to indicate a service probe without any content. It looks like roslisp may be unhappy about receiving a service request with probe=1.

It looks like roscpp detects and handles the same situation without needing the probe field. Maybe here: https://github.com/ros/ros_comm/blob/indigo-devel/clients/roscpp/src/libros/service_server_link.cpp#L137-L165

---

Originally posted by ahendrix with karma: 47576 on 2014-03-11

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by unknown_entity1 on 2014-03-12:
No. The probe connection header attribute is not documented there, or anywhere I can find. I only discovered it by analyzing the byte streams using wireshark, and then found vague references to the functionality in release notes. I autogenerated scripts for discovery before noticing probe exists.

Comment by ahendrix on 2014-03-12:
Adding information about the things you're seeing will help the developers correlate it with the actual behavior of the software. Links to release notes, code, existing docs that you've already found, and wireshark dumps would all be useful.

Comment by unknown_entity1 on 2014-03-12:
Where do you think I should put it? It seems like the TCPROS documentation would only be the right place once the details are known so as not to confuse readers? I'll post here if you think this is the right place. I usually don't get follow up on my comments, so I appreciate your follow through, and I will personally follow through to your suggestions if you reply.

Thanks,

Aaron

Comment by ahendrix on 2014-03-12:
For the purposes of asking about these things, include your background materials in the question. This will prevent answers suggesting documentation that you've already deemed is incomplete.

Comment by unknown_entity1 on 2014-03-12:
Added the information to the Description. Thanks, Aaron

Comment by unknown_entity1 on 2014-03-13:
Off subject do you know the default connect timeout? and does a pub/sub timeout on no activity after x time? If so what is that time duration?

Comment by ahendrix on 2014-03-13:
I'm not sure what the connection timeout is; I suspect it's set by the OS TCP stack. I'm not aware of an inactivity timeout on topics.

Comment by unknown_entity1 on 2014-03-13:
I think your right about topics. Although, the UDP implementation does have a heartbeat bit, yet I don't think it uses it. I didn't see a non-infinite timeout on the code references you shared, however, a comment inside of there made it appear like that was an intent... Thanks for your incite.