trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SunilVasanta <v.su...@sawridgesystems.com>
Subject Re: traffic server configuration
Date Tue, 31 Mar 2015 05:41:43 GMT
Hi Randeep,

Below explanation details on your solution deployment, I suggest you to  
check ATS use case presentation by Linked in. It might help you.

http://www.slideshare.net/thenickberry/reflecting-a-year-after-migrating-to-apache-traffic-server


Thanks,
Sunil Vasanta


On 28-03-2015 01:47, Randeep wrote:
> Hi Alan,
>
> Origin servers are known. The idea is as follows.
>
> We have a VOD service currently available now which can be watched 
> with our own the set top box(Like appleTv). We are currently using 
> Amazon cloudfront CDN. We are planning to have our own data center and 
> moving whatever we have in cloudfront to our data center. This Data 
> center is connected to our Nationwide private VPN where the pops are 
> also connected.
>
> So the origins are known.
>
> When our Set top boxes make a request for a url, the url we have to 
> give is the real head end url or the caching server(ATS) url which is 
> near to that? This is where I got confused with reverse proxy and 
> transparency.
>
> Because this videos in our head end should be accessed in two ways.
> 1. One is via private ip(or private Domain) where the requesting 
> device is connected directly to our network.
> 2. Second is via public ip(or public domain) where the devices outside 
> our private network can access.
>
> So I thought we can put the public domain as the url in the database 
> and the devices accessing from outside can access them with the same 
> domain and the devices accessing the same videos can access via an 
> internal routing for the same domain to the private ip.
>
> Also I would like to know whether the caching server cache the 
> encrypted video chunks? Because all of our videos are encrypted. I 
> heard like the CDNs like Akamai doesn't cache encrypted videos.
>
> Will it work this way?
>
> Best Regards,
> Randeep
>
> On Fri, Mar 27, 2015 at 7:16 PM, Alan Carroll 
> <solidwallofcode@yahoo-inc.com <mailto:solidwallofcode@yahoo-inc.com>> 
> wrote:
>
>     The best rule is to ask, what is the universe of origin servers
>     you expect to access? If it is finite and known, use reverse
>     proxy. If it is potentially unlimited, use forward proxy. But what
>     real difference this makes, I don't know. Transparency is
>     completely independent of forward/reverse proxy and each side is
>     independent of the other (you can have transparency on just the
>     user agent side, just the origin server side, or both). Getting
>     transparent mode to work can be a bit of a pain (since it requires
>     configuration outside of ATS) so I would avoid it unless you have
>     a specific need for it.
>
>
>
>     On Friday, March 27, 2015 7:31 AM, Randeep <randeep123@gmail.com
>     <mailto:randeep123@gmail.com>> wrote:
>
>
>     Hi all,
>
>     We are configuring an ATS for caching on our network edge points.
>     But I'm not getting how to do it. This is our scenario. We have
>     one central headend where we store the videos and stream live
>     channels and this headend is connected to our nationwide private
>     network(MPLS mesh). We are planning POP(caching) locations in
>     every city. From these pop locations network is connected to
>     junction boxes and from there it is connected to customer devices.
>
>     Inline image 1
>     In this POP we are planning to put Apache traffic server as
>     caching(videos-MPEG DASH Encrypted.) server. I'm confused whether
>     we have to configure this caching server as reverse proxy? Reverse
>     proxy can be configured transparent?
>
>     Is there something wrong in it?Is this the right way to implement
>     this?
>
>     All suggestions are welcome.
>
>     -- 
>     Regards,
>     Randeep
>     Mob: +919447831699[kerala]
>     Mob: +919880050349[B'lore]
>     http://twitter.com/Randeeppr
>     http://in.linkedin.com/in/randeeppr
>
>
>
>
>
> -- 
> Randeep
> Mob: +919447831699[kerala]
> Mob: +919880050349[B'lore]
> http://twitter.com/Randeeppr
> http://in.linkedin.com/in/randeeppr
> 	-- 	
> Randeep Raman
> http://about.me/Randeeppr
>
> <http://about.me/Randeeppr>
>

-- 

Sunil Vasanta
Sawridgesystems


Mime
View raw message