I thought I’d post this on my blog as well since this seems to get a lot of attention nowadays (it certainly seems to get a lot of visitors!).
I just started a new open-source project on SourceForge.net — I know you github fans will jump at my throat for using sf.net and not github, but I’m being pragmatic here: I’m still learning my git commands and way of operating, whereas I’m very comfortable with subversion so rather than spending countless hours each day trying to figure out how to merge in changes in git, I thought I’d go with what I know and spend my time on actual coding rather than admin! Makes sense?
Anyway, the reason for this post is because I need some help with the project (as it’s always the case with open source) so I thought I’d raise awareness to my readers of this — who knows? one of you guys might lend a helping hand?
The project page on SourceForge is http://rmisockfactory.SourceForge.net — that page is the maven site page, you can get the whole wiki’s, downloads etc. at http://SourceForge.net/projects/rmisockfactory/ (though the maven site page links to that so you can use either of those 2).
The project is a Java 6-based project (hence the Duke image ) and uses Maven as the build tool. (As mentioned above, the first project link page was generated by maven and deployed to sf.net through Maven too.) 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.
Now having given you the brief on what the project does, here’s the other thing: I do need some help with testing this — from unit testing it (unit testing sockets is a bitch! ) to running more complex tests, like CPU consumption, bandwidth analysis etc. So if you got some spare time on your hands and the above sounds interesting to you, visit the project page on SourceForge and join or drop me a line here and we can work something out on how to progress with this — I would really appreciate any help, obviously!
Hopefully this post will get more visibility (at least for now) than the project’s own page on SourceForge and I’ll get a few replies (fingers crossed!) — failing that, visit the project page in a few weeks when hopefully I’ll be in a position to make an alpha release of the library.