On Fri, May 16, 2014 at 12:26 AM, Matthew Petach <mpetach@netflight.com> wrote:
You want to stream a movie? No problem; the video player opens up a second data port back to a server next to the streaming box; its only purpose is to accept a socket, and send all bits received on it to /dev/null. The video player sends back an equivalent stream of data to what is being received in.
1. Take the understanding that the media player will return the stream it received. For the sake of expediency and avoiding unnecessary waste (Enhanced efficiency), I suggest the introduction of a new frame format, the "Null reduced frame" and "Null reduced IP packet". This is an IP packet which logically contains N bytes of payload, that is to be transmitted without its payload, but is to be "understood" as having contained those N octets of payload data, for administrative and billing purposes; where N is some number between 1 octet and (2^32 - 1) octets. The media player can then emit these Null-reduced IP datagrams that contain no ordinary physically payload --- a flag will be set in the return packet and the frame when transmitted to indicate, that although the IP datagram physically contains no actual data, it MUST be counted on all device interface counters and Netflow reports as X octets, and treated as having contained N octets for the purposes of billing and peering negotiations. -- 2. Excellent. Especially if the video player receives streams over UDP and doesn't verify the source IP address before sending the stream back, what could possibly go wrong?. 3. On second thought.... why not send the return stream to another subscriber? Stream the thing only to buffer the content to a subset of the users' media players. The users' media players then shape the return stream in order to distribute the content ----- they could even SEND more data back to the content provider than they receive, if this benefits the content provider in peering negotiations. -- -JH