A Rerun Viewer session now matches 1:1 to a Rerun TCP server

[petertheprocess]

What

related issue #6952
When lauched with files rerun xxx.rrd, the viewr doesn't listen to any port.
I am using rerun-cli 0.17.0 [rustc 1.76.0 (07dca489a 2024-02-04), LLVM 17.0.6] x86_64-unknown-linux-gnu release-0.17.0 d65ca50, built 2024-07-08T13:47:55Z.

Before this PR:
No log msg shows we are hosting a SDK sever over some ports.

> rerun /media/Q/eulerBackUp/Box/Box/rerun_samples.rrd
[2024-07-20T19:37:04Z INFO  re_data_loader::load_file] Loading "/media/Q/eulerBackUp/Box/
Box/rerun_samples.rrd"…
[2024-07-20T19:37:04Z INFO  winit::platform_impl::platform::x11::window] Guessed window s
cale factor: 1
[2024-07-20T19:37:04Z WARN  wgpu_hal::vulkan::instance] Unable to find extension: VK_EXT_
swapchain_colorspace
[2024-07-20T19:37:04Z INFO  egui_wgpu] There were 2 available wgpu adapters: {backend: Vu

> rerun
[2024-07-20T19:38:40Z INFO  re_sdk_comms::server] Hosting a SDK server over TCP at 0.0.0.0:9876. Connect with the Rerun logging SDK.
[2024-07-20T19:38:40Z INFO  winit::platform_impl::platform::x11::window] Guessed window scale factor: 1
[2024-07-20T19:38:40Z WARN  wgpu_hal::vulkan::instance] Unable to find extension: VK_EXT_swapchain_colorspace

After this PR:

> target/debug/rerun /media/Q/eulerBackUp/Box/Box/rerun_samples.
[2024-07-20T19:43:09Z INFO  re_data_loader::load_file] Loading "/media/Q/eulerBackUp/Box/
Box/rerun_samples.rrd"…
[2024-07-20T19:43:09Z INFO  re_sdk_comms::server] Hosting a SDK server over TCP at 0.0.0.
0:9876. Connect with the Rerun logging SDK.
[2024-07-20T19:43:09Z INFO  winit::platform_impl::platform::x11::window] Guessed window scale factor: 1

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using examples from latest main build: rerun.io/viewer
  • Using full set of examples from nightly build: rerun.io/viewer
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!
• If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

• PR Build Summary
• Recent benchmark results
• Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

[Wumpf]

Thanks for fixing this! Don't see any reason why we wouldn't listen on tcp after loading a file either.

[Wumpf]

python wheel build is a known failure. waiting for rust lint ci to finish, then merge

[teh-cmc]

This will break the ability to open multiple files in parallel.

Today, you can do e.g. this:

$ rerun file1.rrd  # in terminal 1
$ rerun file2.rrd  # in terminal 2

This will open two Rerun windows, one for each terminal.

This works fine because these two windows don't bind to any port, and so they cannot conflict with one another.

With this PR, this would now fail:

$ rerun file1.rrd  # in terminal 1
$ rerun file2.rrd  # in terminal 2 -- ERROR: port 9876 taken

You'd have to do this instead, which is really weird from a UX standpoint:

$ rerun file1.rrd              # in terminal 1
$ rerun file2.rrd --port 9877  # in terminal 2

Automatically switching the second viewer to another port that's available isn't really a solution either: it's very impractical to have a bunch of Rerun Viewers automatically open on different random ports.

I believe the correct solution is for rerun file.rrd to redirect the data to the already listening viewer for that port, if there is one.
To force-open a new viewer, the user can use --port XXXX as before (and if that port is also already taken, then the forwarding logic applies once again).

Related:

• RecordingStream should be able to forward an existing RRD file #2044

[teh-cmc]

(Added details)

[petertheprocess]

I believe the correct solution is for rerun file.rrd to redirect the data to the already listening viewer for that port, if there is one.
To force-open a new viewer, the user can use --port XXXX as before (and if that port is also already taken, then the forwarding logic applies once again).

This make sense, I can work on it. But I can't do that till Thursdy.

---

Here comes another question: how to detect a exist viewer and the corresponding Port?
I am not sure does the egui framework have some support for that?

Or we can create a temp file which logs the existing viwer's status, every time launch a new instance, we check this file.
@teh-cmc @Wumpf any idea?

[petertheprocess]

I found that currentlly rerun_sdk handle multiple spawn by simplly assuming the port is running a Rerun Viewer.
[2024-07-23T21:11:25Z INFO re_sdk::spawn] A process is already listening at this address. Assuming it's a Rerun Viewer. addr=0.0.0.0:9876

[teh-cmc]

Yes, for now you should just assume that if a port is taken, Rerun is what's bound to it.

In the future we will need to make this more robust, see:

• Introduce a Rerun handshake for checking if a viewer is running on a given port #4019

( ⚠️ make sure to make a new message if you want to ask us a question -- if you do an edit, we do not get a notification, even if you tag us! 😱)

[petertheprocess]

Sorry for the late reaction,
Now I have added the port checking logic for cli as #4019 did. But I cannot find a way to stream the file to current active recording.

....
   } else if is_another_viewer_running {
        re_log::info!("Another viewer is already running, streaming data to it.");
        // get current active recording
        use re_sdk::RecordingStream;
        let static_ = true;

        let Some(active_recording) = RecordingStream::get(re_sdk::StoreKind::Recording, None)
        else {
            anyhow::bail!("No active recording found!");
        };
        // map is lazy, so we need take the result by let _ = ...
        let _ = args
            .url_or_paths
            .iter()
            .map(|path| active_recording.log_file_from_path(path, None, static_));
        Ok(())
    } else {
...

I am tring to use re_sdk's log_file_from_path to do that, but I can't get access to the recording in a running viewr. In python api, it seems like a new recording will be created if a viewr is running. But I think the best default behavior should be streamming to the active record so that we can megre 2 .rrd file or append new log to a existing one. Any idea?

[petertheprocess]

@Wumpf @teh-cmc

[Wumpf]

But I think the best default behavior should be streamming to the active record so that we can megre 2 .rrd file or append new log to a existing one. Any idea?

Sure that would be a nice variant, but that's not what passing files in does today either. E.g. when passing in two images to rerun cli, it creates two application ids one for each image.
Which essentially means that there's two recording streams. There's no real concept of querying a RecordingStream since a recording stream is just a utility to send data to a server. If you'd really want to stream to the same recording, you'd use the same application id and recording id and things would merge upon arrival at the server. But again, I don't think that's what we want here anyways.

[teh-cmc]

I like it! Thanks