Full-duplex communication with the Grizzly Framework
I just read Rex Young's very interesting blog Turn a HTTP connection into a full-duplex communication
Basically he uses HTTP Chunked Transfer Coding to create a full-duplex communication between client and server.
Well I recently joined the Grizzly Project as a committer.
One of the first things I did is write a Tutorial on How-to write a custom protocol with the help of Grizzly.
In a way this custom protocol is very similar to HTTP Chunked Transfer Coding.
- They both use fixed length headers to denote the size of their payloads
- They both just use one connection
- They both can send data in chunks
- They build on TCP/IP
- Ready to go infrastructure
So I thought it should be very easy to come up with a Grizzly Demo version of Rex Young's Port Implementation And here it is. If you want to build the source you'll need to download
- Grizzly Port sample source code >(http://weblogs.java.net/blog/johnmann/archive/storage/full-duplex-grizzly-src.zip)
- Rex Young's sample source code source code (http://weblogs.java.net/blog/rexyoung/archive/storage/full-duplex-http-src.zip) depends on
- The latest grizzly-framework with samples module 1.8.6(grizzly-framework-samples.jar)
The Grizzly sample classes have two main classes CustomProtocolClient.java and CustomProtocolServer.java.
CustomProtocolClient has one important method:
RemoteCall callRemote() throws IOException
RemoteCall is just a holder of an InputStream and OutputStream which gives a client a way to receive and send bytes to it's server.
So to fulfill Rex Young's Port.java contract I just have to do a remote call and hand DefaultPort.java both streams.
On the other server side CustomProtocolServer will receive the client call with :
So again all I have to do is hand DefaultPort both streams.
So why might an Grizzly Implementation be worth considering when needing a full-duplex communication between client and server?
- First of all the server is build on Grizzly. So if a Server needs to scale Grizzly Asynchron IO gives you lots of possibilities.
- Threading is no problem. Just issue in another Thread a call to callRemote(). For Example a Heart Beat could be implemented in this way
- If you have doubts because you are using CustomProtocol instead of HTTP. Well you can use the Proxy Http Tunneling Technique mentioned here
to simulate a HTTP Connection. Actually the Sample Client has a connect method with a Http Tunnel Implementation
- You could tailor the underneath Protocol to your needs.
So at the end I like to again thank Rex Young for writing such an great entry and giving me a theme for my first blog.