Discussion Board

Results 1 to 2 of 2
  1. #1
    Registered User
    Join Date
    Apr 2006
    Prague, The Czech Republic

    Total Rx/Tx stats for a socket

    Hello all,

    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?

    Best regards

    Marian Kechlibar

  2. #2
    Nokia Developer Expert
    Join Date
    Sep 2011

    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 [4] 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) [5] to intercept outgoing packets[6]. Such outbound post processing hook [7] 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 [8] 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 : http://www.developer.nokia.com/Resources/Support/

    Kind Regards,
    (V) - Mike - known at Dibo as /dev/null

    [4] http://library.developer.nokia.com/i...nOverview.html

    [5] http://www.symlab.org/main/documenta...B47FF950E.html

    [6] http://www.developer.nokia.com/Commu...ng-TCP-packets

    [7] http://www.symlab.org/main/documenta...26E68C9B7.html

    [8] http://www.symlab.org/main/documenta...CD56397C3.html

Similar Threads

  1. Replies: 12
    Last Post: 2010-04-20, 23:37
  2. SIP plugin TX an 400 after RX an INVITE
    By Zaibach in forum Symbian Networking & Messaging (Closed)
    Replies: 0
    Last Post: 2004-08-06, 11:29
  3. TX RX SMS through a TDMA Mbus protoc
    By tomasalfonso in forum PC Suite API and PC Connectivity SDK
    Replies: 1
    Last Post: 2003-08-28, 19:09
  4. Nokia 22 TX/RX/Sidetone Levels
    By nicrome in forum General Development Questions
    Replies: 0
    Last Post: 2003-06-10, 14:56
  5. RX, TX, DTR and DCD Signal Levels
    By cl_zigzag in forum Symbian
    Replies: 1
    Last Post: 2001-12-03, 22:38

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts