Multicasting and Switches

TCP - it's documented under the heading "TCP file transfers". Either a raw stream is sent in response to a NeedFile request (if the needer advertised a port number), or a simplified HTTP-style raw request-response, if the needer responds to an advertised port in a WillSend promise.

The two forms are needed in case one system has a (software?) firewall.

Everything is checked through SHA-1 hashes. If a file reaches its expected size but the hash doesn't match, the whole file is dropped (since there's no way to know where the error occurred) and the search starts afresh.

Yes.

Yes, but beware that a single dropped packet at the source will cause every recipient to send a NACK. This is the problem with massive wide-area reliable multicast protocols, they get you out of the data fan-out problem but replace it with a NACK fan-in one instead. That's also why some routers have been taught how to aggregate such NACKs.

If you're dealing with tens or hundreds of machines on a LAN, it's probably not an issue - low error rate and it's possible to cope with the NACKs. Even if many of them are dropped, it only requires one to get through and the requested section will be multicast again.

I expect that due to startup timing differences, you'd need to sit and listen for a relevant multicast to start for a few seconds before requesting it... or to wait after receiving such a request for a few seconds before starting to send.

Include identification inside the stream so latecomers realise what they're missing and can re-fetch the earlier parts.

The other thing we considered doing with massive multicast involving overlapping sets of parties was to allocate 2**N multicast groups, and take N bits of the SHA-1 of the file (or channel ID, if not using content-addressing) to decide which IGMP group to send it to. That way a smart router can refrain from sending packets down links where no-one might be interested.

Clifford Heath.

One way would be to break up the message into numbered blocks with CRCs and use a simple carousel to repeatedly broadcast those blocks. This is used e.g. for firmware updates for TV STBs, in which no return channel is available.

Each receiver accumulates blocks and if you did not get all blocks during the first cycle, wait for the next carousel cycle to pick the missing blocks.

If there is a return channel, each slave could initially request all blocks, after one full cycle check which blocks are missing and only request those missing blocks. After each full cycle, the server would check all the update requests received during the cycle and drop those blocks from the carousel which have not been requested, those speeding up the update cycle, finally shutting down the carousel.

If the expected error rate is low, the missing blocks could be asked even with unicasts.

If the expected error rate is high, such as in some radio links with large blocks, a memory ARQ system could be used, in which blocks failing the CRC are stored and if subsequent reception(s) of the same block also fail the CRC check, the previously received blocks are accumulated, until the accumulated block passes the CRC.

Alternatively, the few missing blocks could be transmitted again with a better ECC coding or just send the actual error correction bits to be combined with the ordinary received data block bits (assuming proper interleaving) at the receiver.

Yes but all "unicast" (i.e., connection oriented protocol)... the "need-er" and the "have-er" engage in a dedicated dialog.

Hmmm... not sure I see why (though my brain is frozen from lying on the roof for the past hour :-/ )

Understood. You don't split the file into "pieces" (though, conceivably, one could "pre-split" the REAL *files* into smaller "files" at the expense of a tiny bit more overhead...

Yes.

I'm looking at a hybrid approach. As always, the initial assumptions drive the design...

Let "the" image server multicast (or even broadcast, depending on the domain of the recipients) *THE* image. Let hosts that end up "missing" parts of that image request those parts from their peers (assuming *some* peers have received the parts). So, this can happen concurrent with the rest of the "main" image's delivery (i.e., it doesn't need to be a serial activity).

I have to look at the model and how it would apply in mesh networks (where your peer is often responsible for forwarding traffic from other nodes -- i.e., the "image server") to see what the overall traffic pattern looks like. It might be a win for that peer to broadcast/multicast that "piece" in the event other hosts (i.e., those downstream from *you*) have missed the piece as well.

Things seem to get harder, not easier :>

Yes. A short delay and allow "need-ers" to pick up the stream at arbitrary points (by cutting it into pieces) instead of having to listen from the beginning (request the parts you missed, later)

Exactly. And, if they can request those parts from peers to distribute the traffic better...

I'm not sure I follow -- isn't *everyone* interested?

Or use RTCP timestamps to synchronize the streams.

Latency? Why would you have noticeable latency? You can start playing the media before the buffer is full, then stretch it a bit to allow the buffer to catch up.

The back channel, here, would see very little traffic (when compared to the forward channel). So, aside from the requirement that it places on the "image server", its impact is relatively small.

I was thinking of a protocol that could offload this "missed block" portion of the process to peers who *may* have correctly received the block. This should fare well when transposed to a mesh topology -- where your peer may, in fact, be your actual "upstream link" (so why propagate the request all the way upstream if your peer can -- and, ultimately *will* -- handle it?)

Rather than "requesting all blocks", I envision requesting a larger object (e.g., a file or an entire image). *Assume* it will arrive intact at each consumer (concurrently). Then, handle the missing parts as I described above. So, the image server is, effectively, the "peer of last resort" if no other *true* peer can satisfy the request -- this might be handled with something as simple as a timeout (i.e., the image server deliberately ignores these requests for some period of time to allow "peers" to attempt to satisfy it, instead).

Huh? Perhaps you meant "until the failing block also passes the CRC"?

Now you've lost me. Why change ECC (you've got horsepower on the Rx end so a "less effective" CRC doesn't really buy you much of anything)?

But you can only synchronize to the granularity that the "buffering discrepancy" in the switch allows.

Each consumer would need to be designed with a "deep enough" buffer to be able to handle any dropped packets, short-term network overload, etc. I.e., if, statistically, it requires T time to restart/resume an interrupted stream then your buffer has to be able to maintain the integrity of the "A/V signal" for that entire duration (else the failure to do so becomes a "noticeable event" to the user).

Consider that some causes of "missed packets" can be system-wide. I.e., *many* nodes could have lost the same packet -- or, packets adjacent (temporally). In that case, multiple (N) retransmission requests can be destined for the server simultaneously. If those are processed as unicast requests, then multiple packet times (N) may elapse before a particular node's request is satisfied.

With video, the user can *tolerate* (though not *enjoy*!) the occasional "frozen frame" -- as long as it doesn't become frequent. (persistence of vision)

With audio, it's much harder to span any gaps. You can't just replay the past T of the audio stream without it *really* being noticeable.

You also have to be able to re-synchronize the streams *after* the "dropout" (imagine two displays/speakers side by side; the image/sound from each must be in phase for a "pleasing A/V experience" :>). So, you can't just "stretch time" to span the dropout.