More of a functional one this... I'm working on a personal project at the moment related to some automated diagramming tools I developed some time back. This calls for inter browser communication (between browsers running on different clients) for which web-sockets are the logical choice in these delightful1 HTML5 days. I've developed a prototype to test out web-sockets in Java using the same connection for both commands (messages between client and server) and for inter browsers comms (messages between clients).
It's only a prototype to test that messaging works but if you head over to The Red Lion2 you may be able to join me online for a virtual pint.
Developing web-socket applications in Java is relatively straightforward though the examples online tend to forget about thread blocking by sending messages to clients in sequence (one client blocking could cause delays to other users). The code I've developed avoids this via use of Java concurrency libraries which is fine except that it violates JEE rules by spawning it's own threads. It's currently limited to a single server and doesn't support a clustered environment which would require either a persistent datastore (less than desirable) or server-server comms (which I'd prefer). I did some test on the LAN to pump messages pretty quickly through the tiny Atom server I have running and it seemed to hold up to the task. Interestingly Chrome started to lock up though IE, FF and Safari seemed to cope. I should try and get some stats on this.
As a prototype there is no authentication (feel free to lie) and no logging of message content (you'll have to trust me on that one or check out the code).
In case you're interested, the code is on github.com, no warranties (as ever).
1 If you've developed in a pre-HTML5 world then you'll know what I mean... If you're still having to support non HTML5 compliant browsers then.. sorry :(
2 The Red Lion is the most common pub name in the UK.
No comments:
Post a Comment