Thanks for the response, it's good to know that I am at least on the right track.
Rogan On Wed, Feb 15, 2017 at 5:32 PM Leonardo Gomes <[email protected]> wrote: > Hi Rogan, > > That sounds like a good structure. You may want to check the Proxy example > as well: > > > https://github.com/netty/netty/tree/4.1/example/src/main/java/io/netty/example/proxy > > You may want to look into MessageToByteEncoder as well. > > I've written a similar thing, but with a pool of channels (using Netty's > pool) as I didn't have any requirement to write on a specific outbound > socket, but could take any from a pool of sockets I ended up creating. > > Cheers, > Leo. > > > > On Tue, Feb 14, 2017 at 4:58 PM, Rogan Dawes <[email protected]> > wrote: > > Hi, > > I'm trying to use netty to implement a multiplexer/demultiplexer. Think > multiple streams travelling together over a single socket, then getting > spread out into individual sockets in my code. > > I'm basing it on the example socks proxy code, which seems to have the > basics in place (server and client together). However, I'm trying to figure > out how best to deal with a couple of requirements: > > The incoming traffic (call it downstream) has a stream number, which is > used to identify which stream it belongs to, followed by some flags, > sequence numbers, a length byte, and 60 bytes of data (of which "length" > are usable). Depending on the flags, I will have to open a new client > socket, and link it to the relevant stream number. > > It seems to me that the server pipeline will have a simple handler that > essentially looks up the channel/pipeline associated with a particular > stream, or, if it does not exist, creates it. Each "client pipeline" (call > it upstream) will have a first handler that knows how to process the flags, > verify the sequence numbers, and extract the actual data, then write that > data into the pipeline. It seems like this could be implemented as a > MessageToMessageCodec, right? Packet comes in, ByteBuf of actual data goes > out, to be written to the stream. > > In the reverse direction, any data coming from upstream will have to be > broken up into chunks of max 60 bytes, then put into a "Packet" that simply > gets written to the downstream channel. > > Does this make sense? Does it seem like a reasonable way of structuring > the pipelines? > > Thanks for your help. > > Rogan > > -- > You received this message because you are subscribed to the Google Groups > "Netty discussions" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/netty/7e3124d3-9791-4d4c-8d6e-462735a473b4%40googlegroups.com > <https://groups.google.com/d/msgid/netty/7e3124d3-9791-4d4c-8d6e-462735a473b4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Netty discussions" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/netty/CAEAdJ9ruupfn-7fXvWi1vhW8yg0-DkWFBAqmjymPYRYf%3D%2BfAkA%40mail.gmail.com > <https://groups.google.com/d/msgid/netty/CAEAdJ9ruupfn-7fXvWi1vhW8yg0-DkWFBAqmjymPYRYf%3D%2BfAkA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Netty discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/netty/CAOYdKdj3aasaSdDdYJnRO9BUDMvvCp849oMHfJD32iywM%2Bcvag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
