Networking/Archive/Necko/Dashboard: Difference between revisions
< Networking | Archive
Jump to navigation
Jump to search
m (Manuel Bucher moved page Necko/Dashboard to Networking/Archive/Necko/Dashboard: move to necko archive) |
|||
(8 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{Template:Archived}} | |||
The goal for this feature is to provide an in-browser dashboard to monitor network activity, similar to Chrome's <about:net-internals>. | The goal for this feature is to provide an in-browser dashboard to monitor network activity, similar to Chrome's <about:net-internals>. | ||
== Usage == | |||
Install the following add-on: | |||
https://github.com/valenting/networking-dashboard/raw/master/networking%40dashboard.xpi | |||
Go to about:networking | |||
== Information to Display == | == Information to Display == | ||
Already implemented by Jiten: | |||
* HTTP(Hostname, Port, SPDY, SSL, Active, Idle) | * HTTP(Hostname, Port, SPDY, SSL, Active, Idle) | ||
Line 10: | Line 19: | ||
* DNS(Hostname, Family, Adress, Expires) | * DNS(Hostname, Family, Adress, Expires) | ||
* Timeline( Total Sent, Total Received | * Timeline( Total Sent, Total Received | ||
TODO: | |||
* RTT | |||
* Cache status | |||
* Protocol version (1.0 vs 1.1, spdy/2 vs spdy/3 etc..) | |||
* half open connections | |||
* time left before idle expiration for http | |||
== Diagnostic Tools == | == Diagnostic Tools == | ||
Line 15: | Line 32: | ||
We'd like to have some diagnostic tools built into the dashboard. In prioritized order: | We'd like to have some diagnostic tools built into the dashboard. In prioritized order: | ||
* Can we ping this host? | * Can we ping this host? (icmp, tcp, tls levels) | ||
* DNS Lookup | |||
* Failed URL test | |||
* Proxy Settings Test | |||
== Tracing/Debugging == | == Tracing/Debugging == | ||
* Basic support for events | |||
* Event Listener for capturing events | |||
* Capture events to file | |||
* Add listeners only for certain events -> B2G monitoring | |||
== Progress and Ideas == | |||
* Implement an event system that allows you to capture the events in the networking stack. | |||
** Should we use nsIObserver or implement a different model? | |||
** Networking components should fire events when needed (Data sent, Channel close, etc) | |||
** Events can be received by 0-many observers | |||
** Should be very lightweight (many events with minimal data, as well as rare events with lots of data) | |||
*** Pushing events probably means we shouldn't use JSON for the format. | |||
** Should report AppID (for B2G) | |||
* Does the WebSocket API use the nsSocketTransportService so we can log it? |
Latest revision as of 08:26, 24 April 2023
ARCHIVED
This page has been archived and its contents may be out of date.
The goal for this feature is to provide an in-browser dashboard to monitor network activity, similar to Chrome's <about:net-internals>.
Usage
Install the following add-on: https://github.com/valenting/networking-dashboard/raw/master/networking%40dashboard.xpi
Go to about:networking
Information to Display
Already implemented by Jiten:
- HTTP(Hostname, Port, SPDY, SSL, Active, Idle)
- WebSocket(Hostname, SSL, Msgs Sent, Msgs Received, Data sent, Data received)
- Sockets(Host, Port, Tcp, Active, Idle)
- DNS(Hostname, Family, Adress, Expires)
- Timeline( Total Sent, Total Received
TODO:
- RTT
- Cache status
- Protocol version (1.0 vs 1.1, spdy/2 vs spdy/3 etc..)
- half open connections
- time left before idle expiration for http
Diagnostic Tools
We'd like to have some diagnostic tools built into the dashboard. In prioritized order:
- Can we ping this host? (icmp, tcp, tls levels)
- DNS Lookup
- Failed URL test
- Proxy Settings Test
Tracing/Debugging
- Basic support for events
- Event Listener for capturing events
- Capture events to file
- Add listeners only for certain events -> B2G monitoring
Progress and Ideas
- Implement an event system that allows you to capture the events in the networking stack.
- Should we use nsIObserver or implement a different model?
- Networking components should fire events when needed (Data sent, Channel close, etc)
- Events can be received by 0-many observers
- Should be very lightweight (many events with minimal data, as well as rare events with lots of data)
- Pushing events probably means we shouldn't use JSON for the format.
- Should report AppID (for B2G)
- Does the WebSocket API use the nsSocketTransportService so we can log it?