Hide pseudo nodes about scope HOT 11 CLOSED

They're not phantom. They're real. Scope is making it clear that your browser is opening lots of short-lived connections to the app. If you install a probe on your local machine, you will see them grouped into the Chrome process. (Or maybe not into a single process given Chrome's architecture, but they'll at least all be labeled Chrome.)

• We can definitely hide any connection we don't see both ends of, or group them (by IP, into a single node, into the Internet) — but then we're losing quite a lot of potentially valuable information.
• These aren't grouped into the Internet currently because the IPs are recognized as local, where local is defined as on the same subnet as any of the interfaces we do have a probe on

I personally have no problem with the current behavior, and even prefer it, as it closely aligns with the idea of Scope presenting "just the facts". But we can prototype other behaviors and see how they feel.

from scope.

I think the problem comes when you have ~10 of these connections hanging around, and they start to detract from the real graph you want to see. I also guess you guys don't see the problem as you are running probes on your local machine - not something I think our intended audience will be doing.

Perhaps an alternative would be to group by unique (local process, port, remote ip), so all the processes connecting to the app from one machine would be grouped into one, but any processes on the same machine connecting to something else would be distinct?

from scope.

For the record, the official term for nodes in a rendered topology that don't come from a probed machine, but rather are just the "other side" of a probed connection, are pseudo-nodes.

It won't be possible to group them based on the other side of their connection. Remember the mapping of physical node to rendered node is done with a MapFunc, which has as input only the node itself (and the 'grouped' boolean). It's also unclear what to do when a single pseudo-node has multiple known connections, or vice-versa.

I'll try 3 versions:

• grouping all pseudo-nodes in the Applications topology by remote IP
• assigning all pseudo-nodes in the Applications topology to the Internet node
• hiding all pseudo-nodes in the Applications topology altogether

and present some options.

from scope.

@tomwilkie alternately, what do you think about just rendering the pseudo-nodes much smaller/grayer than the others?

from scope.

Let me have a play and see what I can come up with.

from scope.

/me bows

from scope.

Heres a poc master...tomwilkie:pseudo-nodes

Its groups together all pseudo nodes connecting to the same addr:port from the same addr.

from scope.

A fine approach, IMO, modulo tests :)

from scope.

Okay good to hear. I've added tests for pseudo nodes being emitted only once per (remote address, local address, local port) and I'm just going to add another test to ensure they are not being "over" merged, and one for non-pid topologies. Any others you can think of?

from scope.

That sounds reasonable — make sure the Network topology test includes a few pseudonodes and we should be good. The pseudonode story isn't strongly tested ATM so I'm just looking for some meaningful attention.

from scope.

Guess this is done now.

from scope.