Time controls

[ryft]

E.g. pause/play/restart/speed up/slow down

[ergovschi]

I think your solution adds a lot of unneeded complexity.

You should have only modified the DataFeeder. The classes TimeControlDataFeeder, TimeControlDataController are useless outside CSVDataFeeder (you cannot speed up time with a real data feeder) and it's not in data controller's logic to do that.

Adding the controls to the panel: Since the right panel extends JPanel you can pass it to the Data Feeder and the feeder can add stuff to it using panel.add() instead of having a special condition inside the RightPanel.

Please don't change the names of the classes. It becomes confusing.

[ryft]

Apologies for not being clear when importing these issues to github, but can we concentrate on completeness before adding extra functionality? It would be nice to get some more visualisations done and have the backend complete before working on any enhancements in earnest.

[DominikPeters]

Thanks for your suggestions, and sorry for misinterpreting everything. I had the time logic in the DataFeeder before, but then some of the visualisation misunderstood a "pause" for "no packets are arriving". I'll try to move things and simplify later today.

[ergovschi]

You can get around that problem by supplying null instead of packets from the data feeder when the system is paused. And then in the data controller when it gets null it doesn't broadcast that new packets arrived.

[ryft]

Perhaps this is the incorrect place to discuss this, but the data controller seems to be providing a lot of single-packet iterations.

By examining the traffic volume visualisation under certain time scales, on most time intervals only one packet is being sent from the data controller on each newPacketsArrived() call. The packets in question are unpredictable and often not the same protocol, but are in line with what we'd expect from that capture, so are clearly just out of position. Large numbers of packets also arrive in regular intervals, so from this view it seems as if there is a timing problem where the graph is updating too fast for the data controller, but ultimately the speed of the graph is dictated by the data controller itself.

However, by looking at the data feeder I cannot see how this problem could arise, as getNewPackets() simply retrieves the next packets from the iterator as intuition suggests is correct. Could it be that the capture really exhibits this strange behaviour? I've convinced myself that it doesn't by opening the CSV in a spreadsheet and charting packets over time. (I'm testing with eduroam.csv but skype.csv seems to do the same).

This is what I'm talking about if you're unsure:

By refusing to process iterations with <= 1 packet arriving, the graph looks like this:

(more like what I'd expect, colours are randomised)

[ryft]

Panic over, apologies for the brain ache. The data feeder was updating per second but the data controller update interval was set to 100ms.

I am now a happy bunny :)