On Mon, Jun 04, 2007 at 04:08:25PM +0200, Oleksiy Stashok wrote:
> Hello Karsten,
>
> here I wrote simple tunnel implementation.
> It is simplified, as write operations are done in blocking mode, but
> hope it will help you.
Thanks a lot. Well, I get AlreadyConnectedExceptions if I connect more
than once, the aquired connector seems to be already in use. What
was the reason I could not allocate a
new ConnectorHandler with new TCPConnectorHandler()? Well, but this helps
also only limited: Every second connection does not work.
I have spend the day to get an own solution, but I failed. The first
SelectionKey which is processed is always OP_READ, not an OP_ACCEPT. I
noticed that the ProtocolFilter chain is only used if no CallbackHandler is
attached (for which
scenario is a CallbackHandler good for, and when a ProtocolFilter if they exclude
each other?), so I attached null to the key after I got a connection. The sources are
attached. I don't know why this programm fails.
I also attached a modified version of the ConnectorHandler interface. A Channel
can now be attached. For me it was useful or the only way I had seen to reuse a the
convenient TCPConnectorHandler.
Best Regards, Karsten
>
> WBR,
> Alexey.
>
> Karsten Ohme wrote:
> >On Fri, Jun 01, 2007 at 05:26:18PM +0200, Oleksiy Stashok wrote:
> >
> >>Hello Karsten,
> >>
> >>let me try to help you.
> >>Let's start from the beginning and will not use cache for simplicity, we
> >>can always add it later...
> >>As I understood, you are not making http proxy, but some tunnel for
> >>socket connections. In other words nothing http specific?
> >>
> >>So I would advice you to start implementing something called... let's
> >>say ProxyProtocolFilter (as Jeanfrancois proposed) :)
> >>To see how you can implement the Filter - please find EchoFilter in
> >>Grizzly/framework test folder.
> >>
> >>As for proxy-to-tomcat connections - please use ConnectorHandlers (to
> >>get one use controller.aquireConnectorHandler(), and don't forget to
> >>release it).
> >>We're working on documentations, but you can take a look at unit tests
> >>we have to understand how you can use Grizzly both for client and server
> >>sides.
> >>
> >>If you'll have questions - please ask.
> >>
> >
> >OK, I have a ProxyProtocolFilter and I also found out that the
> >WorkerThread contains the ByteBuffer. So I would do the following
> >
> >Use the returned ByteBuffer from the WorkerThread aquire a
> >TCPConnectorHandler from the Controller in the Context
> >
> >register a CallBackHandler with a reference to the SocketConnection for
> >the way from client to proxy and an implemented onConnect() method
> >
> >write out the data with write(byteBuffer, true)
> >
> >When do I release the TCPConnectorHandler? I store the TCPConnector with
> >the SocketChannel for the way client-proxy in a Map in the Context. So
> >the connection can be reused. What is better?
> >
> >When the connection is done onConnect gets executed and I can get the
> >SocketChannel for the line proxy - Tomcat server
> >The pair of SocketConnections client-proxy and proxy-Tomcat server is
> >kept in a mapping in the context. This is important to remember who is
> >talking over the proxy to whom.
> >
> >For the way server-proxy to proxy-client I have to write back the data.
> >Problem I see no way how I can use here an TCPConnectorHandler. The
> >TCPSelectorHandler offers no possibility to use an existing
> >SocketChannel. I would change this to simplify my life or how is it
> >intended?
> >
> >Why are there two methods: register(CallbackHandler) and
> >setCallbackHandler(...)?
> >
> >Thanks,
> >Karsten
> >
> >
> >>WBR,
> >>Alexey.
> >>
> >>Karsten Ohme wrote:
> >>
> >>>On Thu, May 31, 2007 at 02:43:43PM -0400, Jeanfrancois Arcand wrote:
> >>>
> >>>
> >>>>Hi Karsten,
> >>>>
> >>>>don't stop the feedback!
> >>>>
> >>>>Karsten Ohme wrote:
> >>>>
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>I want to program a proxy (actually tunnel). All connections are made
> >>>>>to the proxy, the proxy makes some decisions and forwards them to the
> >>>>>server. For my situation many clients connect to the proxy on port 80,
> >>>>>the proxy forwards the requests to a Tomcat server on port 8080 and
> >>>>>writes the response back to the client.
> >>>>>
> >>>>>
> >>>>Stupid question: can the client connect directly to Tomcat or does all
> >>>>connection must go to the proxy? I suspect all connections have to pass
> >>>>through the proxy, but in case not, the proxy can always send a
> >>>>redirect to the client (using the location: header).
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>How can I acieve this with Grizzly? I though I had to extend the
> >>>>>TCPSelectorHandler, overwrite the onAcceptInterest method, establish
> >>>>>there a new TCPConnectorHandler for the path client-proxy and one for
> >>>>>proxy-server and register CallbackHandlers wo propagate the read and
> >>>>>write operations.
> >>>>>
> >>>>>
> >>>>I would not override the onAcceptInterest but instead let the default
> >>>>workflow happen. On of the reason is onAcceptInterest is executed on
> >>>>the same thread as the Selector.select(), which is a performance
> >>>>bottleneck. I would instead implement two ProtocolFilters that uses the
> >>>>newly added ConnectionPool/Cache. My recommendation is to do:
> >>>>
> >>>>1. Use the default ReadFilter to execute the first read to make sure
> >>>>the connection hasn't been closed between the accept() and the first
> >>>>read.
> >>>>2. Add a new ProxyProtocolFilter:
> >>>>
> >>>>+ When initializing, create a pool of connection your remote server
> >>>>(Tomcat). I recommend you take a look at the new ConnectionPool/Cache
> >>>>Alexey demonstrated yesterday at the Grizzly meeting.
> >>>>
> >>>>
> >>>I don't know how to use it. What is a ConnectionPool? There is only a
> >>>class ConnectionCache. What is it useful for? From the name I suspect
> >>>that some sort of connections are cached and I have a method to get free
> >>>connections which I can use. I would expect a constructor with a given
> >>>number where this amount of connections are created. For me this would
> >>>be always the same type of connection from the proxy to the client, for
> >>>the way
> >>>
> >>>from client to proxy I need for each client a single connection or not?
> >>
> >>>What are doing requestReceived(), requestProcessed() and responseSent( C
> >>>conn ). Which connection I have to pass in as parameter? What means
> >>>cached? In the sources it looks like i have to pass the connectiosn on
> >>>my own. From which class must the methods be called? How can I reuese
> >>>such a cached exception when it is idle? There is not get method.
> >>>
> >>>Regards,
> >>>Karsten
> >>>
> >>>
> >>>
> >>>>+ When execute() is invoked, use a StreamAlgorithm implementation to
> >>>>make sure you can read the complete HTTP request (note: you gonna need
> >>>>to buffer the body as well). The module/http sub module have a
> >>>>StreamAlgorithm implementations called
> >>>>ContentLengthAlgorithm|StateMachineAlgoruithm that can be reused.
> >>>>Mainly those classes will make sure the entire headers + body are read.
> >>>>+ Once you have read all the bytes, get a connection from the
> >>>>connection pool and flush the bytes to Tomcat. Make the
> >>>>TCPConnectionHandler.write(bb,TRUE) so the temporary Selector trick can
> >>>>be reused.
> >>>>+ Then read back the response and flush it back to the client.
> >>>>
> >>>>Would that make sense? You might also want to create two
> >>>>ProtocolFilter, one for reading the request, and one for writing the
> >>>>response to the active connection to Tomcat.
> >>>>
> >>>>
> >>>>
> >>>>>But I don't know how the ProtocolFilter fits into the picture. How do
> >>>>>I use it? I also want to use TLS connections. How can I get the data
> >>>>>which is decoded?
> >>>>>
> >>>>>Is there any documentation or tutorial for the new Grizzly API?
> >>>>>
> >>>>>
> >>>>Take a look at the following talks:
> >>>>
> >>>>https://grizzly.dev.java.net/presentations/FISL-2007.pdf
> >>>>http://weblogs.java.net/blog/jfarcand/archive/BOF-4989-Grizzly.pdf
> >>>>
> >>>>We don't have yet tutorials but I'm working on one right now.
> >>>>
> >>>>Hope that help.
> >>>>
> >>>>-- Jeanfrancois
> >>>>
> >>>>
> >>>>
> >>>>>Regards,
> >>>>>Karsten
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> >>>>>For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> >>>>>
> >>>>>
> >>>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> >>>>For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> >>>>
> >>>>
> >>>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> >>>For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> >>For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> >For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net