Hacker News new | comments | show | ask | jobs | submit login
Integrating WebSockets in Netty (github.com)
26 points by dagingaa 1791 days ago | hide | past | web | 7 comments | favorite

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... , 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".

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.

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 :) )

Dropwizard has some examples of "REST server making use of JAX-RS annotations", but then its not Netty, but Jetty.

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

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 :)

My dialog app uses Netty for serving secure web sockets to a Chrome web client, an Android client, and an iOS client. I evaluated several ws client libraries before getting the SSL handshake and websocket handshake working. The most difficult issue was limiting the server-accepted ciphers to those that iOS was truly compatible with.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact