So I have one major problem that is getting in the way, and that is managing flow control over the multiplexed link.
I send a packet with a particular sequence number, and the receiver must ACK it, much like TCP. Each packet may be a maximum of 60 bytes, and I can have a maximum of 14 packets in flight at any one time (i.e. unacked), for performance reasons. In theory, this should allow for retransmission of any missing packets, but in reality, this results in flow control, which is also desirable. However, the one flow control aspect I don't have a good handle on is how to stop reading from the upstream channel. In one case, the Channel is a file, and the ByteBuf that is read contains the entire contents, being 10000 bytes. I have a "chunking handler" that chops this up into 60 byte chunks, which is fine, however, the thread tries to write all 167 chunks one after the other, without giving the receiver a chance to ack. How can I tell the pipeline to stop feeding me ByteBufs for the moment, but to resume when I call read() on the channel? AutoRead is already false, but that doesn't seem to help, because the very first read() results in far too much data being available, and it "must" be processed! Thanks! Rogan On Monday, February 20, 2017 at 9:26:14 AM UTC+2, Rogan Dawes wrote: > > 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] > <javascript:>> 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] >> <javascript:>> 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] <javascript:>. >>> 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] <javascript:>. >> 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/06b2eeaf-b212-4b2c-b738-c89cb5b3d2e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
