There is no support for "nested Pipelines" yet. It may be part of 4.1.0. For now you need to remove/add handlers on the fly.
See [1] for an example.
Frage
I'm pretty new to Netty, but how would one implement a case in Netty 4.x when several protocols (e.g. P1 and P2) are encapsulated inside another protocol?
+-------------+
| decoder |
+-------------+
| encoder |
+-------------+
| muxer |
+-------------+
| demuxer |
+---+------+--+
| |
| |
+------+ +------+
| |
| |
v v
+-------------+ +-------------+
| P1 decoder | | P2 decoder |
+-------------+ +-------------+
| P1 encoder | | P2 encoder |
+-------------+ +-------------+
| P1 handler | | P2 handler |
+-------------+ +-------------+
Is there a way to create nested pipelines, so that decoder<->encoder<->muxer<->demuxer
being the main pipeline would send the data along P1 or P2 pipeline based on the decision of demuxer?
Or maybe there is a way to somehow create (for the sake of clarity) "subchannels" with their own pipelines?
Lösung
There is no support for "nested Pipelines" yet. It may be part of 4.1.0. For now you need to remove/add handlers on the fly.
See [1] for an example.
Andere Tipps
I added the following comment to https://github.com/netty/netty/issues/8544
I have a suggestion how this can probably be achieved in current and older versions of netty.
The basic idea is to define a single 'front-end' pipeline to handle the real socket and I/O including encode/decode. Then distinct 'back-end' pipelines will be invoked for various related protocols (or even separate 'sessions' for protocols where the application layer can run independent sessions over a single connection). Thus the back-end pipelines are protocol or session/dialog specific, the front-end is more general and maps to the single real network connection downstream and knows how to instantiate, retrieve and select from multiple back-end channels upstream.
I see two potential levels of abstraction in Netty where this distinction between front-end and back-end pipelines might be possible:
The most feasible (and heavyweight) is to declare a whole other Bootstrap for each backend pipeline. These backend bootstraps will have to be bound to a custom 'virtual socket' which is actually backed by the 'front-end' netty pipeline. In other words, the virtual socket is not mapped directly to a TCP connection or host/port, but rather is a further endpoint distinction (host, port AND protocol or session), but it maintains a reference back to the single specific 'front-end' channel/pipeline that invoked it.
A less heavy-weight option might be to somehow instantiate (and store and retrieve) new channels within the existing bootstrap. I have hardly begun to investigate how feasible this is. The following questions (and possibly others I haven't thought of) must be answered first: