Unix Sockets address support for Websocket

[ruffsl]

When hosting a foxglove websocket bridge behind a reverse proxy on the same machine, it would be nice to support unix sockets as a host address/port for the websocket server connection. This could be more efficient than redirecting websocket traffic over local loopback network interfaces, with some web servers now natively supporting unix sockets:

• https://caddy.community/t/v2-reverse-proxy-to-unix-socket/7071/5
• https://caddyserver.com/docs/conventions#network-addresses

As a bonus, this could improve the overhead performance/latency in Foxglove Studio as well, if compatible with the Electron app, providing a performative alternative to the deprecated native ROS2 bridge that could've used DDS shared memory transport.

• /~https://github.com/foxglove/studio/pull/5070

As of writing, it looks like the websocketpp library used here has a ticket and PR implementation for supporting unix sockets:

• Listen on unix socket zaphoyd/websocketpp#557
• Unix-Socket Configuration zaphoyd/websocketpp#1013

[defunctzombie]

@ruffsl Is there a bug you want to report here or is this a feature request? If this is a feature request please post this over in the discussions: /~https://github.com/orgs/foxglove/discussions rather than this repo as a bug.

[amacneil]

moved

[ruffsl]

I wanted to file this feature request on the specific repo to where its relevant, rather than defer to a general user form. I find technical discussions easier when github permalink expansion and whatnot are working in the same repo of origin, e.g.:

/~https://github.com/foxglove/ros-foxglove-bridge/blob/f208f96ee13859e257041f750c0334a79e5c33eb/ros2_foxglove_bridge/src/ros2_foxglove_bridge.cpp#L121

The above call sight is where it would be nice to support the unix//path/to/socket address schema, with say port=null.

Feel free to change the label of this ticket to from bug to feature, or transfer this ticket where you'd prefer for your org.

[defunctzombie]

The issue also calls out studio support so we think that's worth having in the general forum for more than one repo. The bridge works in tandem with Studio so the primary driver of adding any feature like this would be Studio and whether we can support this well in Studio.

The linked PRs for websocketpp being dated to 2016 don't give me much hope that this is coming anytime soon.

[ruffsl]

I'll note that the ticket is from 2016, but the PR is from 2021, and builds from the most recent upstream commit from websocketpp, that being from 2020. Although the web standard hasn't changed much, I suspect the upstream library repo is no longer being maintained to track future changes to that web standard.

So perhaps it's worth considering migrating to another library, with at least active security updates. If that next library also supports unix sockets, so much the better. But then I'm not sure how much resources foxglove has to vendor and maintain websocketpp currently.