parsing of incomplete / multiple JSON-objects and other extensions about rosbridge_suite

[rctoris]

@baalexander what's the status on #48?? I think it's overdue to pull this in ⛵

[baalexander]

This is not a big issue in many cases, but during my tests for fragmentation and service_requests with huge response-messages, rosbridge constantly was not able " .. to deserialize message from client.."

I haven't encountered this issue. But my use cases tend to be pretty vanilla and rarely publishing large messages from client to rosbridge.

@baalexander what's the status on #48?? I think it's overdue to pull this in

I haven't checked in a while, but the last hurdle was needing unit tests for the changes.

I currently have the code for:

tcp-server
defragmention of fragments sent by clients
enabled fragmentation of outgoing messages
advertising services
unadvertising services
requests to service providers connected via rosbridge

@ipa-fxm-db Let's get this into rosbridge!

• Are your changes for Fuerte? I would love for them to be ported to Groovy/Hydro, but maybe we can get them into Fuerte for now if that's what you're working on and worry about up-porting later.
• Are these features easily breakable as separate pull requests? If so, I think it would be easier to digest in feature-based chunks.

[dabertram]

• my changes are currently for groovy
• it should be ok to do separate pull requests, writing unit-tests for each of them will be somewhat more work

..my current test-script is testing all of those features within one script (huge service requests with both, service-client and service-provider connected via tcp)
I could change it to run automatically and check if the client receives the correct service response, ,,in case an something is not working as it should it would still need some debugging to find the exact rosbridge function that fails..

[rctoris]

Do we need to block on unit tests? I mean, we don't even have full coverage/we have commented out failing tests 🎉

[baalexander]

@ipa-fxm-db I'm glad your changes are for groovy. If you want to start sending in the pull requests (to our groovy-devel or hydro-devel branch, there shouldn't be any real differences), we can start reviewing and accepting them. You can send the giant test script at the end and we can review and merge that one on it's own. Thanks!

[dabertram]

it turned out that it will be more work than I was hoping to separate the features into several pull requests.
mostly because the test script is using all features at once, and I would have to adapt e.g. rosbridge_protocol.py each time to only import the needed classes etc..

I have added a "simple" UML-overview to visualize how the new classes integrate. altough this is not 100% accurate, complete, and not representing the very last code base, it might help to get an idea of the changes I made.
I also included 2 txt-files in the base dir:

• new_opcodes.txt describes how to use the new features and what needs to be taken care of
• README_test_new_capabilities.txt just tells where the test scripts for service provider and a client that calls it are located

Sorry, but I will be busy on the next project, trying to get ROS running with windows.. so I have to leave this open (..up to you) for now.
I guess it will take some time to get through everything, but I tried to leave as many comments as I thought would be reasonable..
There are some TODO's left, I think you will need to decide which of them are critical and which can be left open until someone feels to take care of them.

I tweaked protocol.py to accept 2 new parameters per client:

• message_intervall
• fragment_size

they are described in new_opcodes.txt as well.

protocol.py also is now capable of parsing an input stream with more than one complete JSON-object (see subject of this issue)

short description of the test scripts:

• service provider registers a service that takes a parameter "count" and sends as many random bytes as response. test-script can be configured for the server to set a receiving fragment-size as well as send fragmented responses to rosbridge
• the client sends a service_request to rosbridge (using call_service, which already existed before I started to add changes) and waits for the response. the client can be configured to set a receiving fragment-size, just like the service provider. when the client receives fragments, it tries to defragment those and prints out all received bytes after successful defragmentation

feel free to contact me about any issues with my code at any time..

• maybe it would be reasonable to redesign especially the singleton- and threading-solutions at a later point
• I also had to make some design decisions about whether a service provider can handle multiple requests at the same time or not; I chose rosbridge to queue up any requests until the last one is finished..
• I chose the op-codes just as they came to my mind, and discovered later that call_service is already using the same to send responses back to clients. since that are messages in different directions, I just left it as it is..

maybe you would like to change that and some other things..

again, feel free to contact me about any issue, problem, questions,...

[dabertram]

..not to forget, I re-added the .py extension to the server scripts and added sym-links instead..
this allows to have code highlighting etc for example in netbeans and seems "cleaner" to me

[jihoonl]

Is this issue resolved by the pull request?

[dabertram]

yes