Daisy chaining is too slow for video

[almgong]

The ratio of getFromBuffer and addToBuffer is far too large - we should instead have a tcp window-like implementation that allows you to have x standing interests tasks running in parallel, that pieces together the data before putting into the buffer

[x][x][ ][x] should wait for the 3rd element -> once it comes add all 4 in succession, etc.

[almgong]

Dumb, simple way

• send x parallel interests, when the entire response of all are done, then send to buffer
• and continue

---

Adaptive way

One way: Circular arrays

• have an array of async tasks that are sending interests, etc.
• onData, they will put their data in a circular array (perhaps custom class we make). The async tasks could be in a parallel circ. array, but this would -> space cost. Only one array has to be circular (prob better for tasks to be) as it would control the behavior of the other array (in terms of deletions + additions)
• every so often, check for data to add to buffer by iterating from the "beginning" of the circular array to the "end" or until you hit a null, which is an indication of a missing segment.
• probably sufficient to make 2 new classes (one can be inner), one for circular arrays, and another for providing the parallel changes of a regular array. Inner class should be for circ arrays

[almgong]

---

Another way

Coupled circular array

• really an optimization and simplification of above
• we can have an inner circular array class that exposes the start and end values corresponding to which slots are currently active (either have data or will have data)
• outer class can use these values to continuously send interests, until there are no more open slots
• Every so often, should call a "sendToBuffer" method exposed in the inner class (here is where the coupling begins), that adds data to the video player buffer, and updates the internal parameters (start, end, etc.) as needed.

I like this option the best due to its simplicity (and avoidance of any parallel data structures).

[almgong]

Some skeleton outline for coupled circular array:

loop indefinitely:

1. for all open slots, send interests
2. onData for each interest, put the data portion into the appropriate slot - if any of the data portion has the EOF_FLAG stop outer loop
3. Sleep (wait) for some time, say 1 second
4. Call send to buffer method
5. return to loop
6. on outer loop break, check one last time to make sure that the circular array is emptied (possibly via an instance method) - if not, send all data to buffer

[almgong]

Daisy chaining is actually FASTER with my device, as my device(s) are weaker...

However I think it may be an issue wherein the overhead of creating async tasks overwhelm the benefits of parallelism. We should implement a thread (or a service) that does this...

[almgong]

Implementation of above at: b7d9e57

[almgong]

On second thought, it is very difficult for window to work in a single thread (because we need to sleep in between processEvents() calls (it would kill performance otherwise)... And this alone would defeat the purpose...

So for now, implementing for daisy chaining for benchmarking purposes.

[almgong]

No benefit from using another thread -- avgs 500ms perpacket regardless...

[almgong]

For now, we cannot proceed further on #14 because of the network and device limitation... Best approximation is simply being able to buffer media from multiple devices, and therefore waiting on your own end to watch a video.

This being said, we can still implement seek on consumer end, which will update the seq num appropriately.

[almgong]

Just tried reducing the processEvents timer to ~100ms each, speed improved drastically.

Daisy chaining is a fine method.