Exploring WebSocket traffic instrumentation for DevTools Network panel

43 views
Skip to first unread message

Harshita Yadav

unread,
Mar 6, 2026, 3:01:42 PM (4 days ago) Mar 6
to dart-gsoc
@Elliott and @Samuel

Hi Elliott and Samuel,
I came across the GSOC problem statement - Add WebSocket/GRPC Support to Flutter DevTools Network panel and I would love to contribute to this.

I have been looking into the idea of adding WebSocket support to the DevTools Network panel and wanted to better understand what the traffic actually looks like at the socket level, so I ran a small experiment locally.

To make things concrete, I wrote a simple wrapper around dart:io’s WebSocket that intercepts outgoing and incoming messages. The goal was just to capture a few pieces of metadata for each frame (timestamp, direction, and payload size) and see what that event stream might look like if something similar were surfaced to DevTools.

For example, outgoing frames are intercepted through add() before they are forwarded to the underlying socket:

Screenshot 2026-03-07 at 1.20.03 AM.pngScreenshot 2026-03-07 at 1.22.09 AM.png
Incoming messages are captured by wrapping the listen() handler:
Screenshot 2026-03-07 at 1.23.19 AM.pngScreenshot 2026-03-07 at 1.24.15 AM.png

The wrapper itself just keeps a small buffer of recent events so they can be inspected while the program runs:

Screenshot 2026-03-07 at 1.25.15 AM.pngScreenshot 2026-03-07 at 1.25.38 AM.png

To try it out, I connected to a public WebSocket echo server and built a small CLI tool that lets me send messages interactively:

Screenshot 2026-03-07 at 1.27.53 AM.pngScreenshot 2026-03-07 at 1.28.18 AM.png

Watching the events appear while sending messages made the difference between HTTP and WebSocket traffic clearer to me. HTTP fits naturally into a request/response model, which matches how the Network panel currently displays activity. With WebSockets, though, the connection is long-lived, and the meaningful activity happens at the frame level as messages move in both directions.

That made me think that representing WebSocket activity as a stream of frame events(timestamp, direction, payload size, etc.) might be a natural way to surface it in DevTools.

One thing I’m still trying to understand is where this instrumentation would ideally live. Do you see WebSocket traffic eventually being emitted through dart:developer timeline events (similar to how HTTP profiling works today), or would it make more sense to expose it through a dedicated VM Service stream that DevTools could subscribe to?

If there is a particular part of the DevTools or Dart SDK codebase you would recommend digging into next, I would be happy to experiment further and share what I learn.

Best,
Harshita


Reply all
Reply to author
Forward
0 new messages