use queue_size for publishers

[jonbinney]

rospy publishers hang if one of their subscribers goes out of wifi range. After the TCP buffer to the non-responsive node fills up, writing data to the publisher's socket hangs, causing it to to block and causing other nodes to not receive data. To fix this, the queue_size parameter was added to rospy publishers a while back. It's been bad practice to use rospy publishers without setting queue_size for a while, but this fact hasn't been widely advertised.

With the queue_size argument set to some number, after buffering queue_size messages, messages to unresponsive nodes are dropped. This is almost always the desired behavior. rosbridge doesn't provide the queue_size param, so rospy defaults to the old, blocking style. Starting in indigo this will cause rospy to print a warning: ros/ros_comm#372

This PR sets the default queue_size to 100, but lets it be overridden by adding a queue_size parameter to the json message. I haven't implemented the rosjs side for this, but the default behavior should be what most people want.

To test this, it is useful to have a publisher that sends a lot of data to fill up the queue quickly. Try this: https://gist.github.com/jonbinney/9752997
First, start rosbridge. Second, connect to it with the provided webpage (publishes strings on cmd_vel). Now start two instances of rostopic hz cmd_vel -w3 in two separate terminals. Hit ctrl-z to backround one of them, and after less than a minute the other will hang. After this PR, it won't hang.

[jihoonl]

Related discussion in ros users mailing list.
http://ros-users.122217.n3.nabble.com/RFC-warning-for-lacking-queue-size-for-python-publishers-in-Indigo-tt4020772.html

[tlau]

+1 for merging into hydro. This is making rosbridge unusable for us on a wifi-based robot.

[jihoonl]

thanks.

[jihoonl]

I have created a related issue in roslibjs to support client side as well.

[jonbinney]

Thanks - adding client client side support will be nice, but things should work quite well without it.