Hi Marcel, On Mon, Jul 26, 2010 at 07:41:18AM -0700, Marcel Holtmann wrote:
> > I'm not so sure doing the home/roaming on service level is > > correct. Consider following case: I'm travelling from Germany to Italy > > for a couple of days and then to Switzerland. The roaming statistics > > would not distinguish between Italy and Switzerland. The prolbem is > > that the roaming costs are different for both countries. So I'd like > > to have different statistics for both countries. > > > > If I understand correctly the statistic counters should be in the > > Network objects and not in the Service objects. Counter exposes the > > Service as statistic source. Service could act as statistic proxy for > > Network. In this case the Counter API doesn't have to change. But how > > does this work out with different roaming counters? Counter API has > > justs one home and _one_ roaming dict. Roaming counters could then > > jump when we roam from one Network to another. At least the current > > roaming ID would be nice to have. But then why not just expose only > > one active statistic dictionary with an ID? It doesn't matter if home > > or roaming. > > the network structs will be removed soon. We wanna simplify the internal > APIs of ConnMan on a massive scale. Okay, that's good to know. > And while I see your point with different countries and different > pricing models, it doesn't really matter. The difference here is home vs > non-home (roaming) counting. Not counting on a country level. The point I'd like to make is to distighuish only between home and roaming might not be enough. I have the feeling that naming even naming home/roaming is not really needed. See below. > The main focus is to figure out how much traffic/time you have spent > outside your home network. Agreed ... > In the end, I do wanna record sessions and provide these information > back to the user. So first of all, we have to be able to be doing > exactly this. ... which will provide the additional information needed to say how much traffic/time has been spend on which network. Later, it is possible to merge all counters together into home/roaming statistic, so that application don't have to do it. > I looked at SQLite and RRD and both are a bit too generic and drag in a > bit too much dependencies for my taste. I also looked at RRD and I think it's quite complex. Especially the code for manipulating data only partially loaded into memory. I don't know how much data we should expect to handle. If there is only need for a few kbytes of memory than the code for manipulating offline data is propably larger than the data structure itself :) > Current idea is to store everything under /var/lib/connman/counter/ with > the service identifier (wifi_xxxx_managed_none etc.) and then suffix > like *.info for the summary and *.data for the actual session data. Okay, let me brainstorm a bit... What kind of information would be stored in *.data? - timestamp - number of bytes/... transfered - online time I assume only binary data so that an entry is fixed sized (increase performance and reduce code size). The new entries are always appended. A new entry is added when the Counter accuracy/period threshold is reached. With above probosal it's not clear when a session starts/stopps. Is this needed? Then *.info would then would be something like this: - service name - number of bytes/... transfered - online time for a given period. The fields are updated in place? *.info has to compacted now and then. All *.data files have to parsed again adn again? I wonder how many disk access this solution introduces, especially for the current day information. I assume the smallest unit is day. Maybe this information could just be hold in memory so that there aren't to many read operation from the disk (yeah, I know, flash nowadays :)). > When we have that, then we need to think about how we can present this > to an end user. And my idea here is that we just present it via some > sort of timeline. Simple example would be monthly or daily etc. Okay. Maybe the *.info should already be in the right form so connman doesn't have to parse/format a lot information if a client requests them. Sorry that I have more question then answers. Maybe tomorrow I have more great(*) ideas. thanks, daniel (*) depends on your point of view :) _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
