Menu
▾
▴
Home
RMI Socket Factory
This project was started on the backend of providing a more performance RMI communication in between RMI clients and servers.
By default, the RMI implementation uses blocking IO without any compression of data. For system with high throughput, you might need occasionally a non-blocking implementation or a certain level of data compression to lower the bandwidth consumption.
See the JDK page for rmi client socket factories and rmi server socket factories
The project is a Java 6-based project and uses Maven (version 3) as the build tool. However, don’t let that scare you — the reason I choose those 2 is because that is my standard development environment on a few other projects I work on — at the time I’m writing this, there’s hardly any Java 6 particular features I’m using in the project, and maven makes it easy it seems to plug into any IDE you might use. (Having said that though, one of my ambitions for this project is to implement some components using the Java NIO packages — at which point probably the Java 6 dependency will be justified.)
A bit about the project, which, in fairness, is not rocket-science: its aim is to provide a few handy RMI socket factories and group them in a library. I say handy because by default the RMI implementation in JDK sends the data unecrypted and uncompressed: it simply serializes your objects and sends them over the wire. This is ok for most RMI-based applications, which exchange little data and not at a high rate, but as I said, there are a few issues with that:
- First of all the data is sent uncompressed! If your objects sum up to 1-2kb and you only send a request to your RMI server once a millenium, that’s fine, you won’t perceive this as a problem. If however you send larger objects over the wire you might find yourself using 50-100Kb or maybe more per each request/response pattern. Multiply this say by 100 requests a second and you got yourself a 10Mbyte per second bandwidth consumption. (I said Mbyte — i.e. 8Mbits! So read that phrase again — 10Mbyte = 80Mbits which can get close to 100Mbps bandwidth that is still used occasionally!) Sure, you can do some refactoring and maybe send less objects over the wire, and compute the rest at the other end, but occasionally that might not be possible — so in that case, you might want to have a certain level of compression of packets involved — and this is one of the areas this project could help you with.
- If you are dealing with high throughput (I’m talking 100′s of requests a second) you will find out that your sending and receiving threads are blocked during the read/write process, as the RMI default factory uses blocking I/O. You might want instead (especially if you send and receive these RMI messages through some threadpooling mechanism) to use these threads to do other things when the network layer is still waiting to send or receive packets — in which case you might want a non-blocking (NIO-based) implementation. And again, this library is aimed at helping with that.
- Another aspect highlighted above is the fact that RMI sends the data in clear — so if you’re running your app in a public cloud like Amazon or RackSpace you might be conscious occasionally of potential “sniffers” in your network and might want to protect some of that data. Sure, you can have your objects Externalizable and perform some basic “encryption” on them via an XOR mechanism or some hashing — but needless to say that’s easily crackable. (If someone got to the point where they’re intercepting your RMI packets, you can bet your bottom dollar that it won’t take them long to figure out your “encryption”!) So to overcome that you might want to use an SSL-based implementation or some other encryption mechanism — and this is where this library can help again.
Project maven site can be found here.
Also I did a write-up about this project on my blog which might give you more insights into the project.
Help is needed on this project so checkout the [TODO] page if you want to get involved!
Project Admins:
Related
