The md5sums for service client and server were swapped

[chfritz]

When trying to call services from turtlesim, I got this error:

[ERROR] [1465782638.813189334]: client wants service /turtle1/teleport_relative to have md5sum d41d8cd98f00b204e9800998ecf8427e, but it has 9d5c2dcd348ac8f76ce2a4307bd63a13. Dropping connection.

The wrong md5sum being sent was the one from the response handler. I
double checked that the handler classes themselves were correct (and
they were), but then found that the serviceClient itself sends the
md5sum and picked the respectively wrong one (response md5 on request,
and vice versa).

This commit fixes that.

[chfritz]

Here is the code I used:

rosnodejs.initNode('/my_node', {
  messages: ['std_msgs/String', 'turtlesim/Pose'], 
  services: ['std_srvs/SetBool', "turtlesim/TeleportRelative"]
}).then((rosNode) => {

  const TeleportRelative = rosnodejs.require('turtlesim').srv.TeleportRelative;
  const teleport_request = new TeleportRelative.Request({
    linear: 1.0, 
    angular: 0.0
  });

  let serviceClient2 = rosNode.serviceClient("/turtle1/teleport_relative", 
                                             "turtlesim/TeleportRelative");
  rosNode.waitForService(serviceClient2.getService(), 2000)
    .then((available) => {
      if (available) {
        serviceClient2.call(teleport_request, (resp) => {
          console.log('Service response ' + JSON.stringify(resp));
        });
      } else {
        console.log('Service not available');
      }
    });
});

[chris-smith]

Are you interacting with a C++ or python server? My memory of when I set this up is that this is what worked for me against a python server/client, though that could be inaccurate...

I looked into the genpy implementation and found that the md5 text used for services appears to the concatenation of the service request and response md5 test which would imply that this is still not correct and that we should introduce a Service.md5sum() method to return this value.

We won't be able to fix this in gennodejs immediately though... Would you be able to test out if passing in '*' for the md5sum resolves the issue for you? I believe it should... If so, I'd advocate for going that route for now, updating on the fly generation to provide the desired method, and then resolve the service md5sum issue when gennodejs is able to get that update in.

[chfritz]

I've tested this against turtlesim. Not sure whether that is c++ or python. But just from reading http://wiki.ros.org/ROS/Connection%20Header, I feel confident that ROS expects the md5sum of the request type in the request header and the md5sum of the response type in the response header -- i.e., the way it is now in the PR (client sends request md5sum, server responds with response md5sum). That seems to make more sense than the opposite anyways and is consistent with messages on topics: you always send the md5sum of the message type itself, not the md5sum of what you expect in return.

I don't think there is anything you need to change in gennodejs, assuming it is already generating the correct md5sums in the type classes, which I assume it does.

[chfritz]

ps: you should be able to test this with gennodejs-generated message types as well. My example code is just what I used.

[chris-smith]

I get the error whether I use the response md5sum or the request md5sum when talking to a rospy service. Testing against std_srvs/SetBool, the error message I see - as well as the header we receive in rosnodejs - shows that the md5sum they're sending/looking for is 09fb03525b03e7ea1fd3992bafd87e16, while the request and responses hashes we produce are 8b94c1b53db61fb6aed406028ad6332a and 937c9679a518e3a18d831e57125ea522 respectively. Sending '*' in the header seems to resolve the issue though

turtlesim/TeleportRelative appears to be a unique case here because the response is empty which means that the md5sum for the service that the server is expecting is actually the same as the md5sum for the Request.

[chfritz]

oh I see. Thanks! Yes, I'll try to fix the on-the-fly code.

[chfritz]

OK, I've fixed that now and created a new PR: #25.