swarm/network/stream: RPC to request subscription info

[holisticode]

This PR adds to the debugging information available.

Over RPC, this code allows to request the stream syncing subscriptions and returns them as a map.
It adds a simulation test which over a snapshot requests all subscriptions.
If provided with a -printstats true flag, it will print the results to STDOUT

[nolash]

Reviewed with the disclaimer that I know quite little about the streamer code in general

[nolash]

Why delay and healthy-check?

[holisticode]

The health check is about the kademlia's health. It will be commented out/removed for now until we have it fixed.

The syncUpdateDelay is a streamer's internal delay time after which it starts actual syncing.
It is relevant to this test in so much as we need to wait at least this delay + the syncing duration time before we actually can check anything.

Check https://github.com/ethereum/go-ethereum/blob/c41721da4849f14ae5bb7fb4509ce94f3a155e53/swarm/network/stream/stream.go#L110-L112

and

https://github.com/ethereum/go-ethereum/blob/c41721da4849f14ae5bb7fb4509ce94f3a155e53/swarm/network/stream/stream.go#L184

[nolash]

Can't this also be done with messageevents?

[holisticode]

What do you mean?

There is no streamingStarted event or something like that, and the SyncUpdateDelay is part of the main code, so we need to set it to something and wait for it.

[nolash]

Like also mentioned herer #18284 (comment) what I mean is then the streaming starts that streaming itself is actually devp2p messages being exchanged, no? Those messages could be inspected, I think;

• is it a syncSomethingType
• is it from a peer that hasn't sent this type of message yet

Not sure if I'm making myself clear...

[holisticode]

Yes I already updated the PR to wait for SubscribeMsg

[holisticode]

@nolash can you pls mark this as resolved if you agree or comment further if you think it still needs attention. Thanks

[nolash]

The syncUpdateDelay is a streamer's internal delay time after which it starts actual syncing.

In such cases we should always get the value directly from the source where it's defined IMO.

[holisticode]

@nolash in this case no. If no SyncUpdateDelay is provided, the streamer will set it to 15 * time.Second, which is obviously too long for a test.

Thus we need to set it, which is why it is set to 500 * time.Millisecond for this test.

Check this #18284 (comment) comment please, that has the relevant snippet

[nolash]

The syncUpdateDelay is a streamer's internal delay time after which it starts actual syncing.

In such cases we should always get the value directly from the source where it's defined IMO.

[nolash]

Ohh, dangerous with the literal 4.

In fact, if this is the only way to get a message type then the simulation framework has skipped the functionality enabled in the p2p/protocols layer where you can get the message code from the struct type.

[holisticode]

I changed it to get the code via spec.

As a side note though, our tests are littered with tests using hardcoded message codes (see this very same test file, all other codes are literals).

[nolash]

Let's make an issue for this!

[nolash]

catch the context timeout in a select here?

[nolash]

Actually, are we absolutely sure here that the message is not only sent but the change also processed at this point, resulting in the change in the streamer state?

[holisticode]

At this point we are sure that the message has been received. There is no way currently to make sure that a message has been processed - I dare to say that none of our tests based on listening to message exchange can actually do that. To that end we would need a node-wide event propagation system.

[nolash]

yes that or message acks after state change :)

[holisticode]

Reopened upstream as #18338