4 Replies Latest reply on Apr 27, 2012 4:26 AM by j_1234

    PHDS and caching




      from what I gather, when using PHDS, the per-content encryption key is built from the common-key and the content ID (which in PHDS seems to be the filename).

      When fetching the file manifest (<file>.f4m), a new license is returned every time.

      When fetching the actual file segments (<file>SegX-FragY), no "session" information or similar is sent. However, the resulting file is never the same between downloads.

      However, even if the files differ between fetches, it seems that if I cache the segments, serving the same identical segmentes to different users, the different license have no problem decrypting them.


      Is this something which I can depend on? I.e, I let the manifest requests through every time, so each client gets a their own license. As long as the common-key remains the same, is it safe to cache the segment files, thus allowing us to use regular HTTP caches in front of the FMIS server in order to scale better?


      The diffs in the segment files, how is this explained? Is this the result of different IVs?


      Also, does the development version of FMIS server have any limitation in regards to number of connections or otherwise? The RTMP functionality has max 10 simultanous connections if I recall correct, but the same does not seem to apply for HDS/PHDS. Just want to check if this is the case, or if something in our testing is broken.


      Thank you