Total Rx/Tx stats for a socket
sorry to trouble you with a (probably) trivial question, but I am stuck at a problem that seems to be non-trivial...
We're currently selling a VoIP application whose clients are often abroad, in roaming mode. They wish to keep track of the amount of data actually transmitted over the network (because of the billing, of course). OK; so I created a simple meter that just adds lengths of data sent in both directions. Nevertheless, this meter underestimates TCP and SSL/TLS connections by 10-20%, the difference being probably in TCP instructions, host resolution and SSL/TLS handshakes.
I am aware that RConnectionMonitor can inform me how much data was transferred over a connection upon its deletion. Nevertheless, I can't use this crude approach, as it does not distinguish individual sockets, and only informs about the data once the connection is closed. One connection can serve for multiple sockets - bad.
I would very much like to get the running Rx/Tx stats from the RSocket itself. But I can't find any API for this purpose. I hesitate to believe that there is no method how to get total Rx/Tx stats for an individual RSocket (incl. all the socket-related data like TCP transmission control instructions etc. - basically the items that are charged for by the operator, maybe excluding host resolution, which is within tolerable error margin) - it is just darn too handy for the system developers themselves to miss.
So, is anyone aware of any such API? Say, a special code for the GetOpt() method? There are various arcane codes for that operation - maybe one of them is the correct one?
Re: Total Rx/Tx stats for a socket
The exact answer is a bit complex to this trivial looking question.
The use case of data traffic monitoring  is (traditionally/historically) implemented on the IP layer. At that level no app specific info exists, so, it can be said with good confidence but not absolute certainty, there is no way to monitor each application (RSocket client) independently – at least as provided by the generic commsfw APIs.
For that reason future implementation of such feature to the existing APIs may considered as a highly unlikely event.
The end-to-end socket communications do have however other layers as well. One application may decide to implement IP hook (prt)  to intercept outgoing packets. Such outbound post processing hook  implementation is the Quality of Service framework. One has to be careful when doing so since device is only aware of the inbound and outbound hooks that are known and expected at design time. The delay of some packages due to processing with IP hooks may cause disturbance to the network and may break or harm the connection.
It is expected that MFlowhook  interface is activated on every (TCP/IP) hook and may allow the use a hook prt: something that latches to an existing (TCP/UDP/IP) binding and not creates a new binding. It’s a hook that inspects TCP/UDP packets and such flowhook may query the application UID. On each platform and device it may need to confirm that the resulted API call does suit your purpose and as mentioned earlier the highest care need to be taken when implementing such hooks to maintain the phone network interface responsibility level.
It may be a time consuming process.
If you are confident implementing and maintaining an IP Hook at the networking level with the technical team support, an API partnering process can be started by sending a request to API management team about the required APIs together with the initially selected device and OS details on which the API expected to be used. If they decide that we can do the partnership on API then Nokia Developer support team can deliver the package to you containing the required partnering API headers, otherwise Nokia Developer support team will decline to deliver the package.
I recommend to file a ticket for each and every device you are interested in to run your application : [url]http://www.developer.nokia.com/Resources/Support/[/url]
(V) - Mike - known at Dibo as /dev/null