Decoupling of Remote Request API and Java Serialization

A place to discus the development of leJOS for the EV3. Please do not use this forum to post questions about how to use leJOS or to report problems etc.

Decoupling of Remote Request API and Java Serialization

Postby fuzzycow » Wed May 14, 2014 4:54 pm

This is mostly a question for Lawrie:

I am wondering if it would be possible to decouple the use of Java Serialization and Network communication layer from Remote Request API (non-RMI).

For example - allowing to swap Java serialization for Protostuff/Protobuff or similar would allow the following:

1) Lower performance overhead for EV3, by using more efficient alternatives to Java serialization
2) Immediate ability to interface non-jvm-based languages and tools by serializing to non-java-specific formats such as protobuff or json. This would open a possibility to drive Lejos from Python or Perl interpreter running on a remote machine, or even on Ev3 itself.
3) Allow swapping of transport protocol, e.g.: use UDP
4) With a bit extra work it could be made possible to allow the user to plug in custom classes on top of Ev3 Remote Request API

Please note that I'm not trying to convince you to change your implementation to use another serialization engine, but to allow users to develop on top of your framework using alternative engines.

With great respect, and many thanks for your work :)
fuzzycow
Novice
 
Posts: 28
Joined: Sun Sep 08, 2013 4:33 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby lawrie » Wed May 14, 2014 10:24 pm

I am not very convinced that the current way that the Remote Request API works is the best solution. I wanted to get something working quickly with Android so I went for the simple solution of a single EV3Request and EV3Reply object. These have lots of optional fields. I am not sure how efficiently object streams transmit these. Using another serialization scheme for these messages could be even less efficient. Another possible solution is to have a separate request and reply message for every method, but this would be quite complex with lots of message classes. And a third scheme would be to send each parameter separately. I am not sure which of these schemes would work best with other serialization mechanisms. If we decide which of these schemes is best, it might be possible to separate out the serialization mechanism and allow it to be replaced.

I did investigate use of Google protocol buffers but was not very impressed with the Eclipse support for generating Java code, and did not see much need for interfacing with other languages. I think a separate message per API call would probably work best with Google protocol buffers, but, as I said, that is rather a complex solution.
lawrie
leJOS Team Member
 
Posts: 917
Joined: Mon Feb 05, 2007 1:27 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby skoehler » Fri May 16, 2014 10:43 am

On 1) I have developed a custom serialization mechanism before. But to be honest, I didn't even benchmark it or compared it to RMI. Then again, if the performance advantage would be dramatic, we should probably switch from Java serialization to something else. I haven't looked into alternatives like protobuf. But I wonder whether they would allow us to solve the following issue: Consider an Android App from the play store that has been developed with leJOS 0.8.1. However, the EV3 runs leJOS 0.9.1 where the set fields of some messages has changed. How do the two talk to each other?

On 2) Opening the communication of the EV3 to other programming languages is a good idea. But it requires some thought, protocol design and most important documentation.

On 3) You can't simply switch between TCP and UDP. Of course, you have to implement re-transmission, congestion control, and what not if you drop TCP. Especially if there are messages for which the sender expects a reply. We don't want the sender to wait forever, because the reply was lost. Of course, "lossy channels" (e.g. based on UDP) have their applications. But it's less important then having reliable channels (like TCP provides).

On 4) Personally, I'd like the EV3 remote API do be built on top of some general message transport layer that can be reused to send/receive user-designed messages. However, I cannot tell whether we'll provide something like that at some point.
skoehler
leJOS Team Member
 
Posts: 1399
Joined: Thu Oct 30, 2008 4:54 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby fuzzycow » Fri May 16, 2014 3:34 pm

I know the differences between TCP and UDP - system engineer by profession :)

Its not really a point of importance - if transport part can be changed by developer, then the developer can choose what better suits a particular scenario.

However just to give some background to where I'm "coming from":

UDP is useful for networked logging, sensor data, etc - minimal effort is involved in socket management, so little that you can have each thread having its own client instance. No worries about server being up, connection lifecycle, thread synchronization, etc. For message-based protocols (protobuf) - UDP datagrams are also much easier to manage, then TCP "streams".
Also in some cases of robot teleoperation - there probably won't be much difference between being late to parse a command arriving via TCP, or loosing a UDP message.

I did some experiments with Lejos and UDP communication, mostly focused on datalogging / sensors:
* Wrote (actually cobbled together from multiple examples) an app for Android which sent its sensor values over protobuff/udp to a service running on PC, with eventual goal to
use Android Sensors and TTS for Lejos/Ev3. Sounds similar to what Mindsensors are working on, but far less fancy (and bit buggy). The app worked in request/response model, as unmoderated flood of sensor values would have been too hard for EV3 to handle. Eventually though I got Mindsensors AbsoluteIMU, and put the Android stuff aside for a while.
* A "datalogging over udp" sample provider for lejos, which can be coupled with ScheduledExecutorService -based SampleProvider poller. In this case I used plain text for data, and the result could be plugged into gnuplot stdin for live charts.

I'll gladly share my code, if its of any interest to lejos team.
fuzzycow
Novice
 
Posts: 28
Joined: Sun Sep 08, 2013 4:33 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby skoehler » Fri May 16, 2014 3:57 pm

fuzzycow wrote:I know the differences between TCP and UDP - system engineer by profession :)

Its not really a point of importance - if transport part can be changed by developer, then the developer can choose what better suits a particular scenario.

Most likely, there will have to be two transports, if we implement UDP at all. And the UDP transport won't be allowed for all types of messages. For obvious reasons. Letting the developer chose the UDP transport for certain types of messages is out of question, IMHO.

fuzzycow wrote:However just to give some background to where I'm "coming from":

UDP is useful for networked logging, sensor data, etc - minimal effort is involved in socket management, so little that you can have each thread having its own client instance.

Each thread has its own instance of what exactly? Lawrie also made the same observations that you mention here.

fuzzycow wrote:No worries about server being up, connection lifecycle, thread synchronization, etc. For message-based transports - UDP datagrams are also much easier to manage, then TCP "streams". Also in some cases of robot teleoperation - there probably won't be much difference between being late to parse a command arriving via TCP, or loosing a UDP message.

I don't fancy implementing re-transmission or any of the other things TCP provides. Therefore, I won't consider sending commands via UDP. That doesn't mean, that beside the TCP channels, there won't be any UDP channels. There might be.
skoehler
leJOS Team Member
 
Posts: 1399
Joined: Thu Oct 30, 2008 4:54 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby fuzzycow » Fri May 16, 2014 6:12 pm

I apologize for this developing into what seems like an argument, which I had no intention of happening.

My original question was about possibility of splitting transport/message serialization and RPC layers of remote request API implementation,
When referring to developers I meant any lejos user / programmer (e.g.: me), not lejos team members in particular.
Only potential work implied for the lejos team, should the idea be found to be worth-while, was basic things like removing direct references to Input/OutputObjectStream from RPC classes.
fuzzycow
Novice
 
Posts: 28
Joined: Sun Sep 08, 2013 4:33 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby skoehler » Fri May 16, 2014 6:36 pm

fuzzycow wrote: When referring to developers I meant any lejos user / programmer (e.g.: me), not lejos team members in particular.

I know. I used it in the same sense in my reply.

fuzzycow wrote:Only potential work implied for the lejos team, should the idea be found to be worth-while, was basic things like removing direct references to Input/OutputObjectStream from RPC classes.

Yes, but you mentioned quite a few things that need to be considered. For example, whether it should be compatible to other languages. You mentioned JSON. I just looked it up, and Wikipedia confirms that it's a textual format. That's usually less efficient than some binary format, because it needs to be parsed. I really think, some benchmarks should be done (e.g. how many messages of decent complexity can be serialized/deserialized on the EV3) for different solutions. Protobuf is available for several languages and seems to be binary, that might be an advantage!
skoehler
leJOS Team Member
 
Posts: 1399
Joined: Thu Oct 30, 2008 4:54 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby gloomyandy » Fri May 16, 2014 8:13 pm

I think all that is being proposed here is that the current code is reworked to allow different implementations to be used, not what they should be or that some alternative should become our standard. This is fine as a proposal. I would however like to point out that this is likely to be more work than originally stated, at the very least we would have to implement at least two concrete versions to be sure that the changes actually work, then there is the ongoing issue of ensuring that it continues to work.

Perhaps if no one has any strong objections to the basic idea, someone (fuzzycow? assuming that Lawrie, has no plans in this area) should try putting together a proposed implementation that Lawrie/Sven and anyone else could take a look at and decide if we want to adopt it as the standard implementation. That way we will have a much better idea of the scale of the changes required and the ongoing support it will require.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3946
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: Decoupling of Remote Request API and Java Serialization

Postby skoehler » Fri May 16, 2014 8:31 pm

gloomyandy wrote:I think all that is being proposed here is that the current code is reworked to allow different implementations to be used, not what they should be or that some alternative should become our standard. This is fine as a proposal. I would however like to point out that this is likely to be more work than originally stated, at the very least we would have to implement at least two concrete versions to be sure that the changes actually work, then there is the ongoing issue of ensuring that it continues to work.

Oh! I didn't see it that way. I would like to point out that the type of serialization used often has an impact on the classes that represent the messages. For example, in case of RMI we have readObject/writeObject methods, a serialVersionUID field, and the Serializable interface. I assume other types of serialization may require other methods, interfaces, and fields. If we support 4 different types of serialization with the same set of message classes, that will be a mess, that I wouldn't want to support.
skoehler
leJOS Team Member
 
Posts: 1399
Joined: Thu Oct 30, 2008 4:54 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby gloomyandy » Fri May 16, 2014 8:48 pm

Hi Sven,
I didn't say it would be easy (in fact I suspect it won't be), but I don't know much about this code, so I'm happy for fuzzycow to prove my doubts to be false!

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3946
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: Decoupling of Remote Request API and Java Serialization

Postby fuzzycow » Sat May 17, 2014 7:36 pm

I have went ahead and wrote a small POC, showing how Java Serialization may be substituted for Protostuff/Protobuff serialization.
In essence I wrote a simplified facade / interface for ObjectInputStream and Protostuff/Protobuff serialization, which allowed me to run portions of RemoteRequest code with minimal changes. Then I used protostuff/protobuff runtime schema generation for existing pojo's for automatic ser/deser of EV3Request/EV3Reply

You can download the POC project (with external libraries) from: http://www.fuzzycow.org/dropoff/fuzzybot-remote.zip
Ant build file is included.

You can see how existing code was wrapped at:
* ServerRequestHandler contains an unmodified cut-n-paste from EV3Menu GraphicStartup request handling code.
* RemoteRequestBattery only had its signature modified to use the simplified serialization interface.

Also(Edit):
* Included/copied are only the Battery-related sections of lejos RemoteRequest API implementation, to make the POC more manageable.
* ServerThread classes are nearly identical, and mostly copied from lejos code

A simple benchmark running both client and server on ev3 showed ~91ms per request for protostuff/protobuff, and ~156ms for Java serialization.

The solution is somewhat ugly, but I believe that if I was going to change (as in decouple writeObject/readObject calls and move them to a separate class) existing RemoteRequest code, and not just rewrap / copy-n-paste it) - the implementation would have been much simpler and prettier.

Lastly - this is only an example to demonstrate an idea. I'm not trying to force this implementation, or the idea on lejos team.
fuzzycow
Novice
 
Posts: 28
Joined: Sun Sep 08, 2013 4:33 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby skoehler » Sat May 17, 2014 10:17 pm

I had a quick look. Does your test really send a request over the network and then waits for a reply after each request? If so, aren't you measuring the network latency, basically?
I'd really like to have results concerning the throughput of messages, for example between two threads on the same system with a pipe between them and also between say the PC and the EV3. I can hardly believe that your tests showed a 40% improvement even though the time measured heavily depends on the latency between the two systems. Also, the test may be very sensitive with regards to the use of buffered streams vs. unbuffered streams.
skoehler
leJOS Team Member
 
Posts: 1399
Joined: Thu Oct 30, 2008 4:54 pm

Re: Decoupling of Remote Request API and Java Serialization

Postby fuzzycow » Sat May 17, 2014 11:11 pm

You are absolutely correct that the test is very basic - unfortunately I didn't have more time for something comprehensive.
Primary goal was to see how hard it would be to decouple transport, serialization and rpc.

For basic performance comparison I wanted figures which would easy to compare/reproduce, regardless of network environment or client machine performance.
Both client and server were run on ev3 itself, same jvm instance, and doing basic "request/reply" over a tcp socket bound to loopback address.

You are absolutely correct about throughput - this POC's socket server and client implementation do not allow proper measurement.

But its not surprising that protostuff was faster during basic test - jvm serialization performance is not very good, as acknowledged by most sources.
E.g.: https://github.com/eishay/jvm-serializers/wiki

By the way - I'm not sure if protostuff's own format (variant of protobuf) is supported in other languages then java. However I have now also tested protostuff wrapper for protobuf serialization and it runs at about the same speed as protostuff's own.

I'm yet to figure out how non-jvm client can be "explained" a message schema which protostuff derived from class definition, and to try json (ether via protostuff or jackson).
Unfortunately don't know if I'll be able to get time for that anytime soon :(
fuzzycow
Novice
 
Posts: 28
Joined: Sun Sep 08, 2013 4:33 pm


Return to leJOS EV3 Development

Who is online

Users browsing this forum: No registered users and 1 guest

more stuff