Nobody got any hints for me on this? I tried spinning in the ChannelHandler, waiting for the ack count to increment, but that simply blocked handling of any incoming messages containing the incremented ack :-(
Is there no way to defer handling of a message until a later point in time, triggered by performing a read(), for example? Rogan On Tue, Feb 28, 2017 at 8:56 AM Rogan Dawes <[email protected]> wrote: > 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]> > 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/06b2eeaf-b212-4b2c-b738-c89cb5b3d2e1%40googlegroups.com > <https://groups.google.com/d/msgid/netty/06b2eeaf-b212-4b2c-b738-c89cb5b3d2e1%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/CAOYdKdhQSKeoGhyUJN2RAE_yubY2Dw0SoUYq8E9kygUOYn51qA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
