Closed Bug 897910 Opened 6 years ago Closed 6 years ago

about:networking - calculate total amount of data sent / received

Categories

(Core :: Networking, defect)

21 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla25

People

(Reporter: robertbindar, Assigned: robertbindar)

Details

Attachments

(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130620122336

Steps to reproduce:

We need to trace the total number of bytes sent / received.
Attached patch data usage (obsolete) — Splinter Review
I've used the already existent variables that count the number of bytes sent / received through a socket (an active one) and I've added 2 counters for the bytes transmitted through the now-closed sockets.
Attachment #780892 - Flags: review?(valentin.gosu)
Attachment #780892 - Flags: review?(mcmanus)
Comment on attachment 780892 [details] [diff] [review]
data usage

Review of attachment 780892 [details] [diff] [review]:
-----------------------------------------------------------------

I was thinking we could do this without a lock, but from what I can see, locking is already used when Reading/Writing:
http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSocketTransport2.cpp#350
I think we could just update the values at that point. Patrick? What do you think?
Attachment #780892 - Flags: review?(valentin.gosu)
Comment on attachment 780892 [details] [diff] [review]
data usage

Review of attachment 780892 [details] [diff] [review]:
-----------------------------------------------------------------

you don't need explicit locks because this is all being done from the socket thread and those values are only updated on the socket thread. If you were trying to read it from the main thread then you would need the lock to prevent reading partial updates of the 64 bit counters on some platforms.

::: netwerk/base/src/Dashboard.cpp
@@ +47,5 @@
>          gSocketTransportService->GetSocketConnections(&mSock.data);
>      nsCOMPtr<nsIRunnable> event = NS_NewRunnableMethod(this, &Dashboard::GetSockets);
>      mSock.thread->Dispatch(event, NS_DISPATCH_NORMAL);
> +    mSock.totalSent = gSocketTransportService->GetSentBytes();
> +    mSock.totalRecv = gSocketTransportService->GetReceivedBytes();

I'm pretty sure these want to be moved up to before you dispatch the event and in the if(gTransportService){} block

::: netwerk/base/src/nsSocketTransportService2.h
@@ +74,5 @@
>          return mActiveCount + mIdleCount < gMaxCount;
>      }
>  
>      // Called by the networking dashboard
>      // Fills the passed array with socket information

document that these dashboard methods are socket thread only

@@ +163,1 @@
>      

can you fix this bit of whitespace? (not from your patch)
Attachment #780892 - Flags: review?(mcmanus)
Attached patch data usage v2 (obsolete) — Splinter Review
Attachment #780892 - Attachment is obsolete: true
Attachment #781758 - Flags: review?(mcmanus)
Comment on attachment 781758 [details] [diff] [review]
data usage v2

Review of attachment 781758 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/base/src/nsSocketTransportService2.h
@@ +158,5 @@
>      void   InitMaxCount();
> +
> +    // Total bytes number transfered through all the sockets except active ones
> +    uint64_t mSentBytesCount;
> +    uint64_t mReceivedBytesCount;    

pls remove this trailing whitespace
Attachment #781758 - Flags: review?(mcmanus) → review+
Attached patch data usageSplinter Review
r=mcmanus
Attachment #781758 - Attachment is obsolete: true
Keywords: checkin-needed
https://hg.mozilla.org/integration/fx-team/rev/b05c1dba6ad9
Assignee: nobody → robertbindar
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/b05c1dba6ad9
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.