WebSocket implementation in SVN now

[Andrew Bunner]

On Fri, Jan 8, 2010 at 3:05 PM, "Trustin Lee (이희승)" <trustin at gmail.com>wrote:

> Hi Andrew,
>
> I'm sending this message to you instead of netty-dev because you sent
> your message to me directly, guessing you did so intentionally. :)
>

  (Sort of. My last mail to the list bounced... trying again)

  Below I advocate adding a Protocol Buffer-backed async RPC mechanism to
Netty and point to http://code.google.com/p/capnproto as an example to crib
from.


> Andrew Bunner wrote:
> > Thanks, Trustin! I'm very excited about using WebSockets for a
> multi-player
> > game.
> >
> > Another feature that (I think) would give Netty more widespread appeal is
> a
> > non-blocking RPC mechanism backed by Google Protocol Buffers. Something
> like
> > http://code.google.com/p/capnproto/ but faster and Netty-style. Inside
> > Google, we use Protocol Buffers for server-to-server RPCs (as well as
> > storage). They're extremely flexible. I think it'd be pretty easy for
> Netty
> > to unseat Thrift as the Java server as choice for service-oriented
> > architectures if only it had a decent RPC mechanism out-of-the-box.
>
> Implementing RpcChannel and RpcController looks trivial.  The problem is
> what envelope protocol should be implemented.  It would be the best if
> it's what Google uses internally, but it's confidential, right? :)
>

  Google hasn't open sourced our internal envelope, but a Google engineer
has created an open-source alternative at:
http://code.google.com/p/capnproto/source/browse/proto/capnproto.proto


>
> Perhaps we could simply make it pluggable - HTTP, HTTP-WebSocket, and
> compact binary protocol for example.
>

  Pluggable is a fine goal. One of the benefits of providing an RPC layer
below HTTP is you can get more requests-per-second. RMI, Thrift and Google's
internal RPC mechanism are all free of HTTP headers.


>
> Also, Protobuf does not define what the server side API should look
> like.  Any suggestion?  Perhaps something like the following:
>
>  interface RpcHandler {
>    Message onCall(String method, Message request) throws Exception;
>  }
>
>  interface FutureMessage extends Message {
>    // if this is returned by onCall, RPC response will be sent later
> when this message is ready (just like how ChannelFuture works)
>  }
>

  On the server side, I'd prefer a blocking threading model and use workers.
For example, this service definition in
http://code.google.com/p/capnproto/source/browse/java/test.proto ...

service TestService {
  rpc Hello(HelloRequest) returns(HelloResponse);
}

 ... translates to this server-side interface ...

interface TestService {
  HelloResponse hello(RpcContext, HelloRequest) throws ServiceException;
}

  In capnproto, it generates the same interface for client and server side.
I suggest generating a slightly different client-side interface ...

interface TestServiceClient {
  Future<HelloResponse> hello(RpcContext, HelloRequest)
}

  ... or ...

interface TestServiceClient {
  // Returns immediately. Populates HelloResponseBuilder when done and
invokes
  // Callback.call()
  void hello(RpcContext, HelloRequest, HelloResponseBuilder, Callback);
}


> More advanced stuff like reflection could be done in the higher level
> layer.
>

I don't think you need reflection if you generate the client stub.

http://code.google.com/p/capnproto/source/browse/compiler/protoc-gen-capnproto-java.cc


> WDYT?
>

  I think it'll be non-trivial work to make the client async and type-safe,
especially without reflection (specifically: you need to get into code
generation). But it would make Netty the server of choice for people
building a service-oriented architecture.

  The reason I like Netty for this job is that'a already a fast HTTP server.
Allowing my web servers to talk to each other--and intermediate nodes--with
an efficient binary RPC mechanism is attractive to me.


> > FYI: Somebody wrote up a favorable review of Netty compared to Grizzly
> and
> > Mina just today :-)
> >
> > http://hungconcon.spaces.live.com/blog/cns!1D5DC34DCADA31FF!383.entry
>
> Thanks for the heads up!  I should add it to the site. :)
>
> > On Fri, Jan 8, 2010 at 12:57 AM, "Trustin Lee (이희승)" <trustin at gmail.com
> >wrote:
> >
> >> Hi folks,
> >>
> >> I've just checked in the initial implementation of WebSocket frame
> >> codec, which is based on Mike Heath's patch.  (Thanks Mike!)  It means
> >> now you can write a WebSocket client / server on top of Netty quite
> easily.
> >>
> >> The example server implementation is also available:
> >>
> >>    http://is.gd/5TUhu
> >>
> >> The code is somewhat verbose because the server is supposed to serve the
> >> example HTML page at the same time.
> >>
> >> To run the example, launch the WebSocketServer and open
> >> http://localhost:8080/ in your WebSocket-capable browser such as
> Chrome.
> >>  You will see an input field and a button.  Clicking the button will
> >> send the text in the input field and the server will respond with the
> >> uppercased text.
> >>
> >> Please note that this is just an initial check-in.  I will add more
> >> documentation and some utility class that simplifies the handshake
> >> process.
> >>
> >> Have fun, and please let me know what could be improved! :)
> >>
> >> Cheers,
> >> Trustin
> >>
> >> --
> >> what we call human nature in actuality is human habit
> >> http://gleamynode.net/
> >>
> >>
> >>
> >> _______________________________________________
> >> netty-dev mailing list
> >> netty-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/netty-dev
> >>
> >>
> >
> >
>
> --
> what we call human nature in actuality is human habit
> http://gleamynode.net/
>
>
>


-- 
// http://abunner.com/andrew/blog/

-- 
View this message in context: http://n2.nabble.com/Re-WebSocket-implementation-in-SVN-now-tp4275740p4275740.html
Sent from the Netty User Group mailing list archive at Nabble.com.