IIRC, Wireshark has a dissector for ROS traffic built-in for a few years now. I'm not entirely sure whether it supports services though, but that would be easily checked.

Edit: this one: TCP based Robot Operating System protocol (TCPROS).

Thank you for pointing to this option! However, it does not decode ROS services.

Afaik services use TCPROS as well, so I'm curious why it wouldn't dissect it.

Edit: testing it a bit, it does seem to be able to dissect the request header, but not the payload. Perhaps it doesn't support or achieve reassembly of the stream properly:

As to whether there is a "simple packet structure": afaik there is no single document which describes that. Perhaps wiki/TCPROS comes closest.

Though this is true only for service connection initialisation (every time for non-persistent services, but only once in the beginning for persistent ones). So for my usecase (starting to listen in the middle of the communication), it does not help. But it is good to know, wireshark provides dissection of some ROS messages.

So if you don't know the service types involved, how would you go about dissecting the data? Service payload doesn't seem to include any indication of the layout of the data, which seems to make dissection difficult.

I do know the service type. But for persistent TCP service connection, only first packet contains the header and I am not guaranteed to catch it (most of the times I will not). So my goal was to dissect ROS service message WITHOUT header (which persistent services do not send) of known service. Or at least get some service-unique part...

For me, it is enough to recognise the packet among others (to sniff all packets of one service). Since the service packet is quite long (~ 70 bytes + payload), I supposed there are some bytes telling of what service this packet belongs to (since in one ROS node, more service servers can operate). So far I did simple packet difference and located bytes, which change on different ROS runs for the same service, but that's far from perfect. I also tried to use service URIs (to catch only packets between two ports - client and server), however client port is harder to obtain, can change and this approach is useless for more clients.

Maybe I get a bit off topic in here, but it is a background motivation for my question.

I do know the service type.

well that helps. But from what I remember/saw, plain payload of service invocation does not include any indication of which service type is involved. Interpretation of bytes is dependent on external/prior exchanged information between client and server.

Is it really possible to dissect the data without having witnessed the session setup?

Since the service packet is quite long (~ 70 bytes + payload)

is this always the case? The AddTwoInts service I tested above has a payload of around 24 bytes I believe (a, b and some other number).

So my goal was to dissect ROS service message WITHOUT header (which persistent services do not send) of known service. Or at least get some service-unique part...

yes, so that's what I was referring to. If you miss out the header, the rest if just "random" binary data.

The capture above is from running rosrun roscpp_tutorials add_two_ints_client 1234 5678 (with the server and roscore already running). That's the handshake.

The request data is 10000000d2040000000000002e16000000000000, or:

length: 0x          00000010 (  16)
arg0  : 0x 00000000 000004d2 (1234)
arg1  : 0x 00000000 0000162e (5678)

Wireshark shows me the request data in a separate packet. The dissector does not do any reassembly apparently (I'm not sure it could do that, as ROS comm is on random ports, so it'd probably need to witness roscore's XML-RPC traffic as well to figure out the ports).

I'm interested in this too, so I'm wondering how, without having seen the initial session handshake, you'd interpret this as ROS service payload?

Edit: following the stream does show the complete conversation:

My interpretation was quite naive, I knew values being sent and I looked for them in the raw message :-) . Fortunately, message was short and the payload was in the end, so it went all good.

Ad message size: I think that was my prior misunderstanding, I was talking about the whole TCP message, not just the "ROS" part. So the ROS payload was just a few bytes (see bellow).

From further experiments and looking at the code I found out, that request (now on speaking only about data added by ROS) consists only of 4B of message length + payload (2xfloat32b in my case). Response consists of 1B of reponse status (in my case always 1, see http://wiki.ros.org/ROS/TCPROS) + 4B length + reponse. So I doubt, I can move on from this.

However I noticed, that you can add so called 'Service connection header'. I am not sure, if this is sent with every message, but if so (and first glance on code suggests it), it may solve the problem, because I can add some unique identifier to it to be recognisable. I will test this tomorrow and share the results.

This is, I believe, the relevant code creating a service message and it looks to add only header, if provided and then simply serialised message (plus length byte).

IIRC, the connection header is really only sent during the handshake.

I'm curious to know why you're trying to do this. If possible, could you describe the use-case?

This is, I believe, the relevant code creating a service message and it looks to add only header, if provided and then simply serialised message (plus length byte).

yes, that's the place.

I'm curious to know why you're trying to do this. If possible, could you describe the use-case?

Sure. I need to get service call latency. I experienced some (rare but existing) really high (> 1s) latency service calls during long run (> 5 hours) and I want to find out, if the problem is the network load (TCP packet transport) or elsewhere.