I’m trying to cache segments for a live flash http stream to save incoming bandwidth but can’t as each client gets a unique URL to the same segment like this:
Is there anyway I can tweak the settings to not include the _w{client id} in the URL and make the segment cachable as the segment should be identical independent of client?
It is the wowza session id. Wowza is not setup to be a caching origin for HTTP.
Charlie
Why? Like andreas pointed out, that’s a great advantage of HTTP Streaming.
One of our customers has many hundred employee behind a single IT infrastructure.
They often want to watch one of our videos at the same time. Our servers can handel this, but the bottleneck is the Internet Connection of the customer. We have to segment the videos at the moment (few minutes seqments) and deliver it with a normal apache server (progressive), so the proxy server of our customer can cache the videos!
I will give a big +1 to the feature of cacheable cupertinostreaming and sanjosestreaming segments.
I think what you are doing will, at least, mess up logging. HTTP origin capability is an upcoming Wowza feature. I am not able to give a time-frame, but I would not make this effort now
Wowza segments an incoming live streaming into chunks once and cache for some time and clients downloads these, so why present each client with a different URL to the same chunk?
It’s a big thing being able to leverage on existing HTTP/Proxy infrastructure and that is one of the most important things about HTTP streaming, I believe, so this is very important. I hope others agree with me
It is the wowza session id. Wowza is not setup to be a caching origin for HTTP.
Charlie
Hey charlie (and others).
I’ve been playing with modifiying the session ID, to provide caching for LLNW for a client. I had success setting it to a static value for all connected HTTP clients.
What are the chances that clients could have a chunk collision when SessionID is not unique anymore (two or more chunks, same _bXXXXXXX value)?
Can I control chunking somehow, to limit this from happening?
Hopefully I’m not doing something incredibly stupid and Wowza internals can handle hundreds of clients with identical session ID’s.
Please, strongly correct me if I’m wrong. I can take it
No problem with messed up log files. The big issue is the double usage of bandwith over LLNW and the load coming towards the Wowza Edge from LLNW.
Messed up log files with a broken session ID are the smaller of two evils. If streaming is not impaired in some way, ofcourse. Will be testing it tomorrow.
The problem I already have is with the returned session ID in this case.
I am implementing IModuleOnHTTPSession to override the session ID.
String sessionId = httpSession.getSessionId();
String newSessionId = “123456789”;
getLogger().info("sessionId was “+sessionId+”, changing to "+newSessionId);
httpSession.setSessionId(newSessionId);
According to the server, this works perfectly: INFO server comment - sessionId was 1113769394, changing to 123456789
Only problem is, the returned playlist contains the old sessionId. What interface can I implement, to override this session ID before the playlist is sent to the client?
