Hi Tuure, Thanks for you reply. Answers inline. 2008/8/25 Tuure Laurinolli <[EMAIL PROTECTED]>: > Alexander wrote: > >> *What are the semantics of the messageReceived method (without >> filters)? Will you receive one message per TCP package? Will the same >> ByteBuffer always be reused for the whole message? > > The message handed to messageReceived consists of whatever the network stack > of your operating system was fit. It has no necessary relation to IP > packets. There are certainly no guarantees that each IP-packetful of the TCP > stream will be received as a separate ByteBuffer. > > In fact, the operating system is free to give you one byte at a time if it > wants to. Or give you as much data as fits into your read buffer. Or > alternate between these modes. A sane operating system would likely give you > whatever is in its buffers, provided it fits into the buffer you gave the > syscall. However, the only guarantees you can have of this are > implementation-specific, and the onyl control you have is the read buffer > size.
Ok. This makes sense. I just wanted to know if MINA provided anything above this. Now it is clear that the framework doesn't. > >> How are the >> positions you set interpreted, and will they be reset? This has been >> hinted on this list and in the tutorial for ProtocolDecoder, but more >> thorough documentation would be handy. > > My impression is that each message (ie. ByteBuffer) delivered to > IoHandler/IoFilter via messageReceived is independent - whatever the > handler/filter does with them is its business. I.e. MINA shouldn't touch a > buffer it has given you a reference to. Sounds good. > >> Basically I'm worried about not getting the header in one buffer >> (HTTP header), so it would be fragmented between two ByteBuffers. Is >> this possible? Is there a size limit or so? What if you get a huge >> header? > > Certainly it can be fragmented and delivered over multiple ByteBuffers. Ok, so this means that I need to use some type of local buffering until the header is present, which I could use CumulativeProtocolDecoder for, right? I need this right on the lowest level, to figure out if there is a CRLFCRLF present in the stream or not, before I can start decoding. I also wondered if DemuxingProtocolDecoder does this type of buffering, since it seems to wait until it can find a decoder. But I'm not sure if it selects a decoder per-session or per-package (message), and if there is any buffering involved. > >> *How are you supposed to handle mixed high/low level protocols? For >> instance, if you write a HTTP proxy based on header contents, you need >> to parse the header into an object at first (maybe using >> MessageDecoder)? When the subsequent packages arrive, you will want to >> stream them directly. > > I'm not sure what you mean by high/low level protocols here. To me it seems > that you only mentioned HTTP. What is the higher/lower level here? Well, since I'm writing a proxy, there is the "byte stream" level, and then there is a "http header" interpreted level. Basically, what I want to do is to buffer the stream until I hit CRLFCRLF, then decode the header, read the header properties and then proxy if certain headers are set. If so, I would put a flag in the session, and the next time my protocol decoder gets a message, it can see that the header interpreter put a flag in the session to stream the rest of the contents. For all subsequent packages, they should simply be written to the proxy connection (as set up by the header interpreter). Is that the recommended way of achieving "dynamic proxying"? Regards, Alexander
