Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Rene Mayrhofer <rene.mayrhofer@fh-hagenberg.at>
To: <users@trafficserver.apache.org>
Subject: Re: Proxying to dynamically changing origin servers
Date: Wed, 31 Aug 2011 10:56:00 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.35-30-generic; KDE/4.5.5; x86_64; ; )
CC: "ming.zym@gmail.com" <ming.zym@gmail.com>
References: <ff472d9b-5cc6-4110-81c1-5cddf70f8d02@iris>
 <1314776014.10966.6.camel@zym6400>
In-Reply-To: <1314776014.10966.6.camel@zym6400>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <201108311056.00576.rene.mayrhofer@fh-hagenberg.at>

Thanks for the answers! Based on these recommendations, we will try the Dyn=
DNS approach first. However, ....

On Wednesday 31 August 2011 09:33:29 ming.zym@gmail.com wrote:
> in this case, I think the ddns still be a very good solution for you,
> what you need is:
> 1, setup a ddns, in the intranet, ie a dhcp zone.
> 2, setup the target origin server to update dns using ddns update.
> 3, make sure the proxy server can get your ddns target resoled.
> 4, config TS's hostdb following dns's TTL
>=20
> then you don't need to find someway to do magic mapping, all you need is
> a ddns update with dhcp working.

There is one use-case not previously mentioned in my email: some of the tar=
get origin servers may (as a future extension) not be reachable from the pr=
oxy, but may need to connect to the proxy server and keep the TCP connectio=
n alive from their end (firewall and NAT issues). That is something that is=
 not even in detailled planning stage yet, but I'd like to keep the archite=
cture open for this extension. Would Traffic Server allow us to write a net=
work plugin that would re-use existing TCP sockets to origin servers instea=
d of establishing a new one for each request, or would that go against the =
basic design?

best regards,
Rene

> =E5=9C=A8 2011-08-30=E4=BA=8C=E7=9A=84 14:33 +0000=EF=BC=8CIgor Gali=C4=
=87=E5=86=99=E9=81=93=EF=BC=9A
> >=20
> > ----- Original Message -----
> > > Hi everybody,
> > >=20
> > > [Please CC me in replies, I am not currently subscribed to this
> > > mailing
> > > list.]
> > >=20
> > > For a research project, we currently have an interesting problem to
> > > solve: to connect HTTPS clients to dynamically changing, internal
> > > HTTPS
> > > servers. One approach that we are currently evaluating is to use a
> > > publicly accessible HTTP proxy with CONNECT support to "tunnel" the
> > > HTTPS connections to the internal servers. However, the internal
> > > addresses may change dynamically. The question is therefore if
> > > Traffic
> > > Server can be configured to (or if it is easy to write a plug-in to):
> > >=20
> > > a) be used in "normal" proxy server mode for clients with explicit
> > > proxy
> > > server configuration to use the CONNECT call for some HTTPS URLs; and
> > >=20
> > > b) for the origin server resolving to be done dynamically based on
> > > internal look-up tables. E.g. the URL
> > > https://my-example.local.com/whatever specified by any client in the
> > > CONNECT request should be mapped to host 10.20.30.40 (the HTTPS
> > > server
> > > may use my-example.local.com as its server address, but the IP will
> > > change dynamically).
> >=20
> > It seems to me all that is required is to set the DNS TTL very low.=20
> >=20
> >=20
> > > I am aware that this is a mix between reverse proxy functionality
> > > (mapping to internal servers) and normal proxying (CONNECT to
> > > client-specified, different URLs). Based on the SDK documentation, I
> > > am
> > > also unsure which kind of plug-in would be required to make this
> > > work.
> > > The backup plan is to use a "normal" proxy with dynamic DNS for
> > > resolving the internal IP addresses, but we would like to avoid this
> > > complexity if possible.
> > >=20
> > > Are we on the right track and is this possible with Traffic Server?
> > >=20
> > > best regards,
> > > Rene
> >=20
> > i
> >=20
>=20
>=20
>=20

=2D-=20
=2D------------------------------------------------------------------------=
=2D---
Prof. (FH) Priv.-Doz. Dr. Ren=C3=A9 Mayrhofer
Professor for Mobile Computing

School of Informatics/Communications/Media
University of Applied Sciences Upper Austria
=46H O=C3=96 Studienbetriebs GmbH
Softwarepark 11
4232 Hagenberg/Austria
Phone: +43 (0)7236 3888-2823
=46ax: +43 (0)7236 3888-2899
E-Mail: rene.mayrhofer@fh-hagenberg.at
Web: www.fh-ooe.at

=46irmenbuchgericht/Court of registry: Landesgericht Wels
=46irmenbuchnummer/Company registration: FN 236729 g