MulticastReceiver

An API that allows web applications to join a multicast (S,G) and receive authenticated, congestion-safe multicast IP traffic from services that offer it.

It provides:

• per-packet authentication
• an origin-based security model
• protection against over-subscription

This lets browsers join in subscribing to popular live media events or file downloads (software or pre-recorded media) that make use of multicast IP to enable the efficient use of network and server resources.

See the explainer for more info.

What is evt.data at mr.onmessage = function(evt) { processPackets(evt.data); }?

This would potentially provide solutions for the question at https://github.com/guest271314/MediaFragmentRecorder/issues/8.

A rudimentary example of a similar concept: Given “an idealized computer with unlimited resources” (https://en.wikipedia.org/wiki/Kurt_Gödel#Incompleteness_theorem) an “infinite” MediaStream beginning at current time 0 once began any individual that has access to the Internet can add media to the stream - multicast to any individual that has Internet access - where the MediaStream is capable of being recorded as the timeline is “infinite” is will be possible to select both played time slices and future (as yet unpublished and broadcast) time slices as discrete media files, and/or a series of linear or assymetric time slices of merged media fragments resulting in a single recording https://next.plnkr.co/edit/Axkb8s.

What is evt.data at mr.onmessage = function(evt) { processPackets(evt.data); } ?

It will be an array of packet objects that provide a per-packet receive timestamp and the packet contents.

In an early prototype this was an ArrayBuffer containing a single packet payload, but I’m pretty sure that’s not going to work.

I’m hoping to update the prototype and nail down a design that will work ok using shared memory to transfer from the receiving service to the renderer for a block of packet payloads, and to expose those packets to the javascript with a receive timestamp and access to the payload data.

But there are details I don’t know exactly what they’ll look like yet, so I didn’t put it in the examples yet. (For instance, I want to make sure the timestamps can be used easily for some math, so I might not use DateTime, but rather a float-second or integer-microsecond offset from a DateTime. There’s still some TBDs here, sorry…)

Conceptually extending EventSource and BroadcastChannel and potentially including use of scheduler.postTask() could provide a tentative means to achieve the requirement.

I’m not sure I fully understand this, but this API doesn’t support any sending from the browser, it’s only for subscribing to channels that someone is sending, and it requires the sender to have some infrastructure in place. So I’m not sure this API does anything directly to help with reflecting media to others from a browser, if that’s the intent.

Did not state that this API is for sending. A “multicast” requires content to be broadcast. There are already mechanisms in place to “stream” data, e.g., this comment. It is logical at the outset to consider the various forms of content that can and will be “multicast”. While this API does not provide such an upload of data from the browser given the fact that individual tend to tire of any content rather rapidly after digesting such content once unless the content is unique and exceptional and the number of images, video and audio that individuals and organizations upload to various media streams, it is reasonable to estimate that by some means data uploaded by individual users will be “multicast”, if not directly by this API, indirectly as a feed of content to this API.

I agree that it would be possible to operate a service that accepts data that users upload and sends it using multicast IP to everyone who’s subscribed to a feed, with data arriving through this API. Thanks for clarifying, I hadn’t properly understood what you meant.

Was describing own face value interest in the concept with reference to actual code composed to achieve that requirement. “media” encompasses various forms. “media” could be plain text or mark up result of speech recognition. In which case the “medium” would be text, not encoded images or audio. Meaning arbitrary limits on what a concept is capable of or should be confined to in language in a document (specification or code) are not static. With that fact realized the basic concept of an API can be extended without undue reliance on only the concepts drawn by the individuals that initially write the draft. The intent of the comments was simply to share what immediately recognized as similar concepts. Perhaps that is not the case. Shared anyway to verify. Cannot put the intent of the comment clearer than DeadPrez It’s Bigger Than Hip-Hop

In the real world
These just people with ideas
They just like me and you
When the smoke and camera disappear

Cool, well thanks for the interest, and I appreciate the comments.

You’d need to handle loss and out of order packets, and the message size would be limited to a packet payload in size, so there would be a lot more hassle than EventSource (until there’s another library wrapped around it to give something closer to EventSource), but if your audience size is big enough and inside networks that forward multicast, it could be worthwhile.

Out of order and packet loss can tentatively be handled by using a header similar to HTTP_LAST_EVENT_ID. Though if the stream is live you could not insert a packet into the past ex post facto. As long as the packets are proximal before the read/write at the client (e.g., after N packets read, sort, supply to device for display or other API for processing) lexicographical order can be achieved; essentially the reverse of this pattern How to read and echo file size of uploaded file being written at server in real time without blocking at both server and client? where the client takes the place of the server.

Also, this API, once implemented appears to be a viable workaround or comparable approach for fetch("/path/to/", {method:"POST",body:new ReadableStream({/*...*/})}), see https://github.com/whatwg/fetch/issues/439, https://github.com/whatwg/fetch/pull/425.

There is no prohibition from the multicast originating from and being transmitted from the browser itself, correct?

I don’t think there’s any way to originate UDP Multicast IP packets from the browser itself, and this API does not provide one. That would come with a much more complicated set of security problems, for instance as covered in this document:

• https://www.w3.org/TR/tcp-udp-sockets/#interface-udpsocket

The proposed MulticastReceiver API tries to expose a much smaller capability, with (hopefully) much less capacity to cause security issues, and that therefore should not require special permissions.

The intent is that the permissions necessary are equivalent to the permissions needed to download streaming content from the same origin as the web page originating the requests.

Have you tried to do so?

When an individual or institution claims a procedure is not possible (or, in fact claims anything) that claim requires verification by means of the scientific method and/or the historical record. Have repudiated such claims more than once in various domains (within the domain of code with code demonstrating what was claimed was not possible is in fact possible).

AFAICT WebRTC has the ability to generate UDP. “from the browser itself” could be interpreted as including Native Messaging, without the restriction explicitly listed, where if JavaScript is not capable of generating UDP Multicast IP packets, which do not gather why that would be the case, the incoming UDP Multicast IP packets can be intercepted, reverse-engineered and reproduced, or a shell script can be used, the results of which can be messaged to “the browser itself” and transmitted externally from “the browser itself”.

I haven’t tried to do it, no. It’s out of scope for the intended purpose.

But also, the proposed API probably would prevent web apps from succeeding at the suggested kind of peer-to-peer multicast in practice, even if it’s possible to get the browser to emit multicast packets.

In order for the packets to be received by this API at a remote peer, they’d also need to receive an authenticated AMBI stream, advertised via a DORMS server with CBACC info that provides rate limits.

(If the source is inside a NAT that the receivers are outside, it would probably get more tricky still, but I think those barriers would already be pretty severe for most web apps.)

I’d be interested to see a script that did send multicast packets from a browser, but I don’t think that would be sufficient to enable the usage I think you were asking about.

To be clear: I’m not completely sure it’s impossible to make this work with sufficient effort from the sender, but the API is very much not designed for that use case, and I expect that even if it’s possible, it would be much easier for the sender to operate a service that accepts messages from the sender and transmits them to subscribed receivers from that service.

If I understand the use case you’re asking about, it might be possible that future extensions might help it, but I doubt this API can do it directly from one browser to a bunch of others. (However, it could help with making an external server that could relay messages to many others.)

I hope that helps to clarify.