Support Network Inspection

[eugeneo]

Network domain is what Chrome DevTools (and any other interested frontends) use for inspecting the HTTP and WS traffic in the browser. This document provides some insight into Chrome DevTools UI and here is a description of the protocol for obtaining that data.

We propose to introduce a Node specific agent that would expose the same (or subset) of this protocol to enable the UI. It does not seem possible to share the implementation between Blink and Node.js.

This agent would also introduce an API for the modules to report the events. E.g. WebSocket modules should be able to notify the agent when WS frames are sent or received.

[sidorares]

would be great to have support for node tcp/udp as well, not sure if that can fit into existing UI and debugger protocol

[jkrems]

Would it make sense to use trace events as the interface to the agent? That would also provide an interface for 3rd party modules (e.g. Websocket) out-of-the-box.

I'm not sure if tcp/udp would become confusing because it's another level than the others. Would http requests show up twice effectively? But having a story for things like memcached's TCP protocol would be great. The obvious/hacky solution would be for them to pretend to be websocket frames.

[eugeneo]

Looks like trace events might be usable for this. HTTP requests/responses might get quite big - I wonder if there's any limit on event sizes...

+@matthewloring, @ofrobots - would it be possible to use the trace events framework for this? E.g. inspector would have an agent that "listens" on event categories and then sends inspector protocol notifications.

[jkrems]

One thing I ran into with a similar feature in bugger: Retaining all request and response bodies in the process can become problematic, especially when there's no easy way to disable it. E.g. "hey let me profile this app while sending a couple of thousand of requests through it to find that memory leak" - aaand you're running out of memory because all request/response bodies are being kept in memory by the agent.

[matthewloring]

There is not currently a mechanism for observing trace events as they are generated. We could explore this in the future once the design in nodejs/node#9304 solidifies.

[alnorris]

Would it be possible to monkey patch this? Similar to how node inspector does it?

[paulirish]

@alnorris honestly it looks like the existing monkeypatch from node-inspector (Injections/NetworkAgent.js) would get pretty far.

The emitted events would just need to make their way to the InspectorAgent

[joshgav]

My architecture proposal in nodejs/node#7393 is largely about allowing implementation of Domain.Method dispatchers other than those tied directly to V8, which is all we have now. The Network domain implementation we're discussing in this thread could be handled by just such an alternate dispatcher if our architecture allowed it.

Allowing alternate dispatchers would a) allow complete alternate implementations, e.g. for other runtimes like Chakra or SpiderMonkey; and b) facilitate one-off (monkey-patched?) alternate or additional implementations for specific Domains and Methods.

/cc @kfarnung who's been looking into such a rearchitecture and Inspector's impact on e.g. Node-ChakraCore more deeply.

[joshgav]

Perhaps a way to facilitate inspector "addons" would be to update NodeInspectorClient::dispatchMessageFromFrontend to route based on the Domain name. That is, Debugger, Profiler, Runtime, and all the domains handled by V8 would be routed to V8Inspector as they are now; and others like Network could be routed elsewhere.

[joshgav]

@eugeneo I changed the title so it would be more obvious what this issue is about, please change back if you disagree. Thanks!