Re: http fsys - dlna compliance 7.4.32.2 - MTMaximum Byte Size Transfers
John Stirling <[email protected]>
| Newsgroups | gmane.comp.multimedia.helix.devel |
|---|---|
| Message-ID | <[email protected]> |
I was hoping someone familiar with httpfsys could point me in the right direction. It's not easy to work out what's going on in there. I've already fixed a couple of other minor DLNA blockers in there, but this one seems like it needs a big change and I'm fairly nervous about breaking something else in the meantime. John Rishi Mathew wrote: > Hey John, > > We havent tested for DLNA compliance internally, this has been > typically done by partners like yourself. You will need to drive this, > we can provide you the help that you need to fix this issue. If you > ask specific questions related to the code/architecture, someone will > definitely answer. > > Cheers, > Rishi. > > At 01:24 AM 9/8/2008, John Stirling wrote: >> Any response to this ? >> >> John Stirling wrote: >>> We tested with an atlas build and it still crashes. >>> >>> We're getting fairly close to needing to get this fixed. >>> >>> Is helix used in any DLNA certified products ? It seems like this >>> would be a fairly common requirement , at least for the bigger >>> brands. So any chance this could get fixed by someone at helix/real >>> ? If not, could someone more familiar with httpfsys give us some >>> assistance in fixing this ? >>> >>> John >>> >>> >>> Eric Hyche wrote: >>>> >>>> I would guess that Content-Length's or Chunked-Encoding-Size's >>>> greater than 4GB will be a problem. Content-Length is probably >>>> not as big of a problem. >>>> >>>> Eric >>>> >>>> ============================================= >>>> Eric Hyche ([email protected] <mailto:[email protected]>) >>>> Technical Lead >>>> RealNetworks, Inc. >>>> >>>> >>>> >>>>> >>>>> -----Original Message----- >>>>> From: >>>>> >>>>> [email protected] <mailto:[email protected]> >>>>> [ >>>>> mailto:[email protected]] On >>>>> Behalf Of John Stirling >>>>> Sent: Tuesday, June 17, 2008 1:03 PM >>>>> To: Greg Wright >>>>> Cc: >>>>> >>>>> [email protected] <mailto:[email protected]> >>>>> Subject: Re: [Helix-client-dev] http fsys - dlna compliance >>>>> 7.4.32.2 - MTMaximum Byte Size Transfers >>>>> >>>>> Greg Wright wrote: >>>>> >>>>> >>>>>> >>>>>> John Stirling wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> We're running our cayene build through the DLNA compliance >>>>>>> >>>>>>> >>>>> >>>>> test suite. >>>>> >>>>> >>>>>>> >>>>>>> There is a requirement to handle content-length, chunk-size, range >>>>>>> fields with values up to 2^48. Currently this test crashes helix - >>>>>>> the crash point being an attempt to dynamically allocate 2Gb in >>>>>>> CHTTPFileObject::DecodeChunkedEncoding. It looks like >>>>>>> >>>>>>> >>>>> >>>>> helix is only >>>>> >>>>> >>>>>>> >>>>>>> set upo to deal with a max of 2^32 currently ? >>>>>>> >>>>>>> Before I look into this in detail, is anyone aware if this >>>>>>> >>>>>>> >>>>> >>>>> has been >>>>> >>>>> >>>>>>> >>>>>>> fixed in a later version of httpfsys ? If not, any pointers to an >>>>>>> easy fix appreciated. I'm currently assuming that converting >>>>>>> appropriate variables in httpfsys to u64 will probably do it (I'm >>>>>>> working on the defintion of 'appropriate') >>>>>>> >>>>>>> >>>>>> >>>>>> I assume it is crashing because the alloc returns NULL (no >>>>>> >>>>>> >>>>> >>>>> alloc that >>>>> >>>>> >>>>>> >>>>>> size possible) and the NULL is de-refed? >>>>>> >>>>>> We did do some work in this area to detect bad chunk sizes >>>>>> >>>>>> >>>>> >>>>> I remember. >>>>> >>>>> >>>>>> >>>>>> And, that method on 310Atlas is different then on 150Cay. >>>>>> >>>>>> >>>>> >>>>> So, my guess >>>>> >>>>> >>>>>> >>>>>> would be yes. You still wouldn't be able to just alloc any amount >>>>>> of >>>>>> memory you want, but it shouldn't crash. The only way to >>>>>> >>>>>> >>>>> >>>>> tell though, >>>>> >>>>> >>>>>> >>>>>> for you case, is to test it. >>>>>> >>>>>> >>>>>> >>>>> >>>>> Apart from avoiding this specific crash, do you think atlas is also >>>>> likely to handle content-length, chunk-size etc values >>>>> greater than 32 bit ? >>>>> >>>>> >>>>> >>>>>> >>>>>> --greg. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Helix-client-dev mailing list >>>>>>> >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> >>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> Helix-client-dev mailing list >>>>> >>>>> [email protected] <mailto:[email protected]> >>>>> >>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Helix-client-dev mailing list >>> >>> [email protected] <mailto:[email protected]> >>> >>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev >>> >> >> _______________________________________________ >> Helix-client-dev mailing list >> [email protected] >> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev > > > *Rishi Mathew > *Helix Community > *Real* Networks, Inc. > [email protected] > _ http://www.helixcommunity.org > <http://www.helixcommunity.org/> > http://www.realnetworks.com/products/support/devsupport.html > _ > _______________________________________________ Helix-client-dev mailing list [email protected] http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev