Jeanfrancois Arcand schrieb:
> 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).
Every connection must pass the proxy in both directions.
>
>
>>
>> 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.
> + 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.
Mmmh, sounds difficult, but I will look into the sources what this
means. I do not want to handle only HTTP connections, there are tunneled
also pure socket connections which have a decribing string of there type
in a proprietary header. I will see what the StreamAlgorithm is good for.
>
> 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.
Thanks, Karsten
>
> -- 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
>