Hide pseudo nodes

[tomwilkie]

I'm not sure phantom is the right term, but these are connections for which we don't have information about one end:

Right now, we should all the connections. Its only three above, but I've seen it be as many as 10, and its tends to dominate the view then.

We could:

• Hide connections unless we see both ends
• Group them together into on (we have a "The Internet" blob - why are these not grouped into that?)
• Group them by IP
• Leave the current behaviour

I'm leaning towards (1), but could be persuaded by (2) or (3). What do you guys think?

[peterbourgon]

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.

[tomwilkie]

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?

[peterbourgon]

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.

[peterbourgon]

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

[tomwilkie]

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

[peterbourgon]

/me bows

[tomwilkie]

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

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

[peterbourgon]

A fine approach, IMO, modulo tests :)

[tomwilkie]

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?

[peterbourgon]

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.

[peterbourgon]

Guess this is done now.