CODEWITHSUNDEEP
netty
Joshua Warner
Joshua Warner

Reputation: 4825

Custom Netty ServerChannel implementation

I have two systems I'd like to integrate, one which uses a completely in-house networking stack, and one (specifically Flazr) which uses Netty. I want to proxy the Flazr Netty-based RTMP stream over our in-house HTTP stack, to yield a system that speaks RTMPT.

To accomplish this, I need a Netty object that acts like a socket, but lets me do all of the "low-level" stuff myself - basically just wrapping the data in HTTP and passing it down our custom networking stack. In other words, I don't want Netty to manage any sockets for me - I want to insert my own stuff between the socket and Netty.

I suspect that the right way to go about this is to extend AbstractServerChannel and create a *Factory class, but I'm uncertain as to how the rest of Netty expects data to be flowing through the ServerChannel.

My custom ServerChannel need to be able to:

Any pointers on how ServerChannel, ServerChannelFactory are to be implemented? I found the javadocs rather lacking in this area.

Some specific questions:

Thanks!

Before anyone asks: YES, I would love to replace our custom networking stack with a Netty-based one, but that's a large engineering task that I'd have a hard time justifying. Baby steps.

Upvotes: 3

Views: 2714

Answers (1)

Jestan Nirojan
Jestan Nirojan

Reputation: 2486

Its look like, you are trying to implement a new asynchronous transport, so it will be worth to have a look on NIO TCP transport (other than Datagram classes).

I am not sure how relevant it is, but it will help to understand how to write a new transport service for Netty (since you have asked about Server, Client Channels, Factories, and all)

It will be easier If you can understand the Netty event model and how goes through the pipeline. This is my understanding about how it works.

  • Upstream events (event from network) starts from Channel/ServerChannel, Boss/NioWorker and send through the pipeline until it reaches the last handler.

  • Downstream events starts from last downstream handler and send through the pipeline and sinks at ChannelSink, channel sink process the events and take action or put the messages on channel's queues.

In more details, (I assume, some one is looking on Nio TCP transport classes to write their custom transport for Netty).

NioWorker - On selector events for the channels (all NioClientSocketChannel, NioAcceptedSocketChannel), runs the nio loop - Data received from network: fire message received - Poll write queue and does non blocking write - Poll task queue for interested op events and take suspend/resume the channel?.

Boss

  • Runs Server NIO event loop.
  • Accept client socket, creates a NioAcceptedSocketChannel, and register selectors for NioWorker

NioClientSocketPipelineSink

  • Has a worker thread pool executor.
  • Submit NioWorker runnables to worker thread pool at constructor.
  • Client channel downstream events sinks here and put to channels write queue/task queue, intercept some upstream state events and manages the state of the channel.

NioServerSocketPipelineSink

  • Has boss thread pool.
  • Submit Nio worker runnables to executor at creation.
  • Submit boss runnable with ServerSocketChannel to executor on bind event.
  • Server channel downstream events sinks here, intercept some upstream state events and manages ServerSocketChannel state.

How should my implementation respond to "InterestOps"-type stuff?

It depends on the nature of the channel (blocking/non blocking) and constrains.

Is ServerChannel.write what is called for messages that come all the way down the stack? What's up with the two different overloads?

Server channel has no need to support those method calls, I think you are referring to Channel's

ChannelFuture write(Object message);

ChannelFuture write(Object message, SocketAddress remoteAddress);

These methods are there for connectionless transport. For TCP, both are actually doing the same thing.

How do I need to implement ServerChannel.(dis)connect?

Server channel doesn't need to support those method calls, but you should implement, bind and unbind here.

Should I still do all of this stuff through ServerBootstrap, or is that too high-level for this stuff?

Server/client bootstraps are just helper classes to manage pipeline resources and provide a facade to bind, connect & disconnect. You have to implement most of the logic in

Client, Server Channel Impls
Client, Server Pipeline sinks
Boss, Worker classes,

Then you have to implement client & server channel factories using above classes, if these things are done, you can simply setup you server & client using Bootstrap classes.

Upvotes: 11

Related Questions