

Integrating WebSockets in Netty - dagingaa
http://comoyo.github.com/blog/2012/07/30/integrating-websockets-in-netty/

======
cgbystrom
I would strongly advise not to base your push mechanism solely on Web Sockets.
Despite advances modern browsers are making with Web Sockets support, the
current compatibility is not there yet.

For starters, IE has no support, though that is starting to change with IE10.
But the biggest issue is with personal firewalls / corporate proxies. These
are unfortunately quite horrible at handling Web Sockets. Many popular
firewalls such as avast! and Bitdefender can’t handle the WS protocol and
completely blocks traffic despite browser support and it being valid HTTP. The
socket.io guys did some extensive research on what firewalls are causing these
issues. I don’t think their list is exhaustive but it features most major
personal firewalls out there. Have a look at
[https://github.com/LearnBoost/socket.io/wiki/Socket.IO-
and-f...](https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-
software) , it's no reading of joy.

I’ve deployed quite large installations of Beaconpush (a push server
incidentally based on Netty as well). First going from Web Sockets with
fallback, over to pure WS and we’re looking at going back to using fallbacks
once again due to these incompatibility issues. This time we are looking at
using SockJS instead of rolling our own (to be fair, there were no open-source
libs doing this when we started). I’ve ported SockJS to Netty
(<https://github.com/cgbystrom/sockjs-netty>) and it’s working although I
wouldn’t say it is production ready.

I urge you to have a look at SockJS and socket.io. Personally I prefer SockJS
since it aims at emulating the Web Socket interface and nothing more as
compared to socket.io (which adds a pub/sub layer). Also, it does not rely on
a Flash fallback (which is another story). The socket.io guys are however
working on engine.io, which will split the transport fallback mechanisms of
socket.io to a separate library. That's a good idea, but it still uses Flash
and IMHO a more complex "transport upgrade".

------
swah
I don't understand why Netty isn't more used for this case, if the support is
there, the library is mature and optimized, the VM is the faster one we have
around...

Perhaps folks that use it aren't the "blogger" kind.

~~~
bborud
I know of a few large production systems that have dispensed with typical
servlet containers completely and are based on Netty's HTTP codecs instead,
but as you said, the people who do these systems aren't necessarily bloggers.

I think this is a very positive trend towards more minimal software and more
self-contained Java servers. Being able to ship (server) software as a single
JAR file with everything you need embedded makes life a lot easier. It is very
nice not having to fiddle around setting up servlet containers, configuring
them, deploying applications into them and then, inevitably, having to restart
everything when a rogue application decides to ruin the party for everyone.
(And it just gets worse when you try to automate it).

One thing I'm still looking for is a good skeletal project for a REST server
making use of JAX-RS annotations, Netty and having support for asynchronous
request handling. Something that we could turn into a really skinny Maven
archetype and teach new programmers to use.

(Obligatory disclosure and shameless plug: I work for Comoyo. If you find
these things interesting/exciting and would like to come work for us feel free
to contact us. We're hiring :) )

~~~
bborud
(I see cgbystrom commented further up and kinda hoped he would whip up a JAX-
RS+Netty+async request processing skeleton ;-) )

~~~
cgbystrom
Totally agree about having smaller and more contained apps.

I used <https://github.com/cgbystrom/jersey-netty> for a one-off project
wiring Jersey together with Netty. But it's not async :)

