The Python Websocket API enables compression by default. When sending large data, this leads to a significant performance decrease and CPU load increase at the same time.
It would be great to have it as a parameter when constructing FoxgloveServer, in order to be able to deactivate it.

It might make sense (probably) to be able to manually set this for all language bindings.

Description

#15 70.52 protobuf/3.21.4: Configuring sources in /root/.conan/data/protobuf/3.21.4/_/_/source/src
#15 70.93 ERROR: protobuf/3.21.4: Error in source() method, line 86
#15 70.93 	get(self, **self.conan_data["sources"][self.version], strip_root=True)
#15 70.93 	ConanException: sha256 signature failed for 'v3.21.4.tar.gz' file. 
#15 70.93  Provided signature: 85d42d4485f36f8cec3e475a3b9e841d7d78523cd775de3a86dba77081f4ca25  
#15 70.93  Computed signature: efdaaf08f34af3b6cd906e59e181e3e30589a2fc2cc9d89036f92d529b9fe1cd
failed to solve: executor failed running [/bin/sh -c conan install examples --install-folder examples/build --build=openssl --build=zlib --build=protobuf]: exit code: 1
#15 ERROR: executor failed running [/bin/sh -c conan install examples --install-folder examples/build --build=openssl --build=zlib --build=protobuf]: exit code: 1
------
make: *** [Makefile:5: build] Error 17
 > [build_example_server 5/5] RUN conan install examples --install-folder examples/build --build=openssl --build=zlib --build=protobuf:

See https://github.com/foxglove/ws-protocol/actions/runs/4047568126 for more details

Expected Behavior
No CPP build failures

Description

../apps/websocket_node/foxglove_websocket/include/foxglove/websocket/websocket_server.hpp:266:37: error: aggregate initialization of type 'foxglove::Server<foxglove::WebSocketNoTls>::ClientInfo' with user-declared constructors is incompatible with C++20 [-Werror,-Wc++20-compat]
    _clients.emplace(hdl, ClientInfo{endpoint, hdl, {}, {}});
                                    ^~~~~~~~~~~~~~~~~~~~~~~

Description

The C++ websocket servers (TLS and non-TLS variants) are configured with per-message deflate, which adds CPU overhead on the server and clients without any bandwidth improvement if the socket is mostly transmitting compressed images. This is a common configuration for robots with one or more cameras.

• Version: latest
• Platform: all

Steps To Reproduce
Include the foxglove_websocket C++ library in a project and use it.

Expected Behavior
Per-message deflate is configurable, and possibly disabled by default.

Description
When using the mcap-record command to record a live stream, if the recording file exceeds 700k (successfully recorded a 608k file), the mcap file will suddenly increase in size. When playing in foxglove, the error message "This file is unindexed. Unindexed files may have degraded performance" or "Chunks without message indexes are not currently supported" will be prompted.

• Version: loaded by npx, it should be latest version I guess
• Platform: windows with node.js. npm version is 10.2.3, node version is v21.2.0

Steps To Reproduce

the python example server could reproduce this. just play it long enough. The file suddenly takes up more space.

mcap.zip
The attachment contains the results of two recordings, with only one frame difference between the two results.
Expected Behavior

When sending data while a websocket connection is being closed / refreshed on studio side, the server side might get the following error:

 future: <Task finished name='Task-1636' coro=<FoxgloveServer.handle_message() done, defined at foxglove_websocket\server.py:182> exception=InvalidState('Cannot write to a WebSocket in the CLOSING state')>
 Traceback (most recent call last):
   File "foxglove_websocket\server.py", line 186, in handle_message
   File "foxglove_websocket\server.py", line 207, in _send_message_data
   File "websockets\legacy\protocol.py", line 655, in send
   File "websockets\legacy\protocol.py", line 1184, in write_frame
 websockets.exceptions.InvalidState: Cannot write to a WebSocket in the CLOSING state
 Task exception was never retrieved

Expected Behavior
No data is sent, but no crashing

Actual Behavior
Exception printed

When streaming recorded data with web socket, we also like to seek back and forth in the recorded timeline or pause the streaming to explore the data.
Recorded bag data do have start and end time, enable play bar will give users the same experience as play a bag file.

Description
I was trying out the Cpp live example_server, and got the following error when I try to view the data. I tried with the python server example, that one works, but not the cpp, can someone can look into that? thanks.

Failed to parse channel schema on example_msg
Error: invalid encoding
at base64.decode (file:///snap/foxglove-studio/20/resources/app.asar/renderer/main.js:434:42123)
at EventEmitter. (file:///snap/foxglove-studio/20/resources/app.asar/renderer/main.js:4808:481)
at EventEmitter.emit (file:///snap/foxglove-studio/20/resources/app.asar/renderer/main.js:1202:12257)
at ws.onmessage (file:///snap/foxglove-studio/20/resources/app.asar/renderer/main.js:4807:210908)

• Version:
• Platform: cpp

Steps To Reproduce

make example_server under the cpp folder.

Expected Behavior
Able to see protobuf message from studio.

Actual Behavior
Shows up the error as what Description described.

Description
I had asked above the Conan version clash issue yesterday (here). Fortunately, a fix was already in the works and it was published a few hours later.

But, now when I am trying to build, I am getting this error:

foxglove-websocket/1.0.0: RUN: cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE="/home/minuszero-ams/.conan2/p/t/foxglbb25eebe40dcb/b/build/Release/generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="/home/minuszero-ams/.conan2/p/t/foxglbb25eebe40dcb/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/minuszero-ams/.conan2/p/t/foxglbb25eebe40dcb/b/."
CMake Error: The source directory "/home/minuszero-ams/.conan2/p/t/foxglbb25eebe40dcb/b" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.

foxglove-websocket/1.0.0: ERROR: 
Package '843428e8a9b40ca5d55e858550cbf6dc3e0054c4' build failed
foxglove-websocket/1.0.0: WARN: Build folder /home/minuszero-ams/.conan2/p/t/foxglbb25eebe40dcb/b/build/Release
*********************************************************
Recipe 'foxglove-websocket/1.0.0' cannot build its binary
It is possible that this recipe is not Conan 2.0 ready
If the recipe comes from ConanCenter check: https://conan.io/cci-v2.html
If it is your recipe, check it is updated to 2.0
*********************************************************

ERROR: foxglove-websocket/1.0.0: Error in build() method, line 38
	cmake.configure()
	ConanException: Error 1 while executing

I am not sure if this is something that can be fixed from your side, or from Conan's. If it must be fixed by Conan, please close this issue. But if there is an issue with my method, please let me know.

• Version:
• Platform: Ubuntu 20.04

Steps To Reproduce

cd cpp
mkdir -p src/foxglove-websocket
cp ../foxglove-websocket/conanfile.py foxglove-websocket/conanfile.py
conan install foxglove-websocket -s compiler.cppstd=17 --build=missing
cp -r ../foxglove-websocket/ foxglove-websocket/
conan create foxglove-websocket -s compiler.cppstd=17

Expected Behavior
The command completes without any errors.

Great job with including websockets as a datasource!

Many panels support / require standard messages formats. It would be great if these could be sent over the websocket json format as well. As an example, consider the 3D Panel that requires sensor_msgs/PointCloud2D.

What is they way to achieve this in Python? I've tried adapting the json server example with the following schema and message, but could not display any points:

schema = {
    'type': 'object',
    'properties': {
        'height': {'type': 'number'},
        'width': {'type': 'number'},
        'is_bigendian': {'type': 'boolean'},
        'point_step': {'type': 'number'},
        'row_step': {'type': 'number'},
        'fields': {
            'type': 'array', 
            'items': {
                'type': 'object',
                'properties': {
                    'name': {'type': 'string'},
                    'offset': {'type': 'number'},
                    'dataype': {'type': 'number'},
                    'count': {'type': 'number'}
                }
            }
        },
        'data': {
            'type': 'array',
            'items': {'type': 'number'}
        }
     }
}

I suppose there are standardized schemas for this, right?

message = {
    'height': 1,
    'width': N,
    'is_bigendian': False,
    'point_step': point_step,
    'row_step': N * point_step,
    'fields': [
        {
            'name': 'x',
            'offset': 0,
            'datatype': 7,
            'count': 1
        },
        {
            'name': 'y',
            'offset': 4,
            'datatype': 7,
            'count': 1
        },
    ],
    'data': list(X.astype(np.float32).tobytes(order='C'))
}

Comparing with the example rosbag, the datatype for data is probably incorrect and one has to send binary data somehow. Also, The 3D Panel asks for a frame to follow - how to specify that over the websocket protocol?

Thanks a lot for your help!

It does not appear that there is currently any way to verify whether or not a server's setup is complete; a function that allows for easily verifying this would be helpful for determining when execution can begin without risk of losing initial data.

At the moment data flow is purely from server to client.
However, in actual robotics environment, user may want to send control signals from the UI to server.
Such feature (eg. Publish) is supported only when using native ROS.
I would like to see this happening on ws-protocol as well.

Description
It seems like there needs to be a lock around some of these functions. I think a channel was added or removed while looping through the channels that needed to be broadcast.

[ERROR] 2022-02-14 16:53:57.092 [:7]: Set changed size during iteration
[ERROR] 2022-02-14 16:53:57.096 [:7]: Traceback (most recent call last):
  File "/tmp/Bazel.runfiles_gerdmrts/runfiles/x/pmx/rover/app/foxglove_bridge/foxglove_bridge.py", line 59, in broadcast
    packet.SerializeToString(),
  File "/tmp/Bazel.runfiles_gerdmrts/runfiles/x/pmx/rover/app/foxglove_bridge/foxglove_websocket/server.py", line 170, in send_message
    for sub_id in subs:
RuntimeError: Set changed size during iteration

https://github.com/foxglove/ws-protocol/blob/main/python/src/foxglove_websocket/server.py#:~:text=)-,async%20def%20send_message(self%2C%20chan_id%3A%20ChannelId%2C%20timestamp%3A%20int%2C%20payload%3A%20bytes,),-async%20def%20_send_json

• Version:
  Latest, the line numbers are off because of our formatter.

• Platform:
  Ubuntu 20.4, Python 3.7 (back-ported types)

Steps To Reproduce
It can probably be reproduced by having one thread broadcast data on a channel, while another repeatedly adds and deletes that channel. It's the first time I've seen this race condition after using foxglove for a couple weeks.

Expected Behavior
No run time error

Actual Behavior
rare race condition

Note - npx may not play well with require – must exclude or figure out.

Description
The spec currently does not support unsetting of parameters. This request came up here: foxglove/studio#5227 (comment)

Description

I find that the C++ implementation in this repo diverges from https://github.com/foxglove/ros-foxglove-bridge/tree/main/foxglove_bridge_base

The implementation of setupTlsHandler() https://github.com/foxglove/ros-foxglove-bridge/blob/main/foxglove_bridge_base/src/server_factory.cpp is missing.

The examples get away by defining empty specialization inside the example source.

Is this intentional? Is it the consumer's responsibility to define this?

Thanks in advance.

• Version:
• Platform: C++ / Ubuntu 22.04

Steps To Reproduce

...

Expected Behavior

...

Nowadays, rather than suggesting protoc --descriptor_set_out, we point people at a technique to generate the FileDescriptorSet at runtime, which is used in mcap libraries/examples:

https://github.com/foxglove/mcap/blob/21b737f99800bfe1d733b769022a726ab3ca4e0e/python/mcap-protobuf-support/mcap_protobuf/schema.py#L17

https://github.com/foxglove/mcap/blob/21b737f99800bfe1d733b769022a726ab3ca4e0e/cpp/examples/protobuf/writer.cpp#L48

We should update the examples in this repo to use the technique.

Description
Running the sample code does not trigger a subscribe event for me when I connect with foxglove studio to the websocket server.

• Version: 1.73.0
• Platform: Linux for webserver, Windows for studio

Steps To Reproduce

import asyncio
from typing import Set, Type
from base64 import b64encode
from foxglove_websocket.server import FoxgloveServer, FoxgloveServerListener
from foxglove_websocket.types import ChannelId, ChannelWithoutId
import google.protobuf.message
from google.protobuf.descriptor_pb2 import FileDescriptorSet
from google.protobuf.descriptor import FileDescriptor

from foxglove_websocket import run_cancellable
from foxglove_schemas_protobuf.SceneUpdate_pb2 import SceneUpdate


def build_file_descriptor_set(
    message_class: Type[google.protobuf.message.Message],
) -> FileDescriptorSet:
    """
    Build a FileDescriptorSet representing the message class and its dependencies.
    """
    file_descriptor_set = FileDescriptorSet()
    seen_dependencies: Set[str] = set()

    def append_file_descriptor(file_descriptor: FileDescriptor):
        for dep in file_descriptor.dependencies:
            if dep.name not in seen_dependencies:
                seen_dependencies.add(dep.name)
                append_file_descriptor(dep)
        file_descriptor.CopyToProto(file_descriptor_set.file.add())  # type: ignore

    append_file_descriptor(message_class.DESCRIPTOR.file)
    return file_descriptor_set


class Listener(FoxgloveServerListener):
    async def on_subscribe(self, server: FoxgloveServer, channel_id: ChannelId):
        print(f"SUBSCRIBED {channel_id}")


async def main():
    server = FoxgloveServer("0.0.0.0", 8765, "example server")
    server.start()
    server.set_listener(Listener())

    topic_name = "sample"
    schema_type = SceneUpdate
    sample = await server.add_channel(
        ChannelWithoutId(
            topic=topic_name,
            encoding="protobuf",
            schemaName=schema_type.DESCRIPTOR.full_name,
            schema=b64encode(build_file_descriptor_set(schema_type).SerializeToString()).decode("ascii"),
            schemaEncoding="protobuf",
        )
    )

    print("Start loop")
    while True:
        await asyncio.sleep(0.05)


if __name__ == "__main__":
    run_cancellable(main())

Expected Behavior
The on_subscription event should be triggered. Confusingly if I create CompressedImage channels in the same way I get the callback triggered.

Description
The data source and foxlove frontend run on different hosts machine, and when I use the cpp example code to transfer a large number of messages, I find that I cannot use up the bandwidth. This causes a delay in the display.

• Version: main branch
• Platform: Ubuntu20.04, mac os m1 pro, bandwidth 100Mbps.

Steps To Reproduce

Expected Behavior
The maximum bandwidth in my test environment was 100Mbps， When I run frontend and ws-cpp on same machine The bandwidth is about 30Mbps, but when i run frontend and ws-cpp on different machine, The bandwidth is about 10Mbps, This causes a delay in the display. But if I run two frontend on a machine, the bandwidth is about 20Mbps (10Mbps per tcp session). But single tcp connect should up to 30Mbps.
So I don't think the front-end rendering is reaching a bottleneck, but is related to a single tcp connection.

Hi,

I can run the python protobuf example and the Foxglove Studio can display it:

But I want it to be useful:

currently only the raw message panel can be used (as show above). What should I do to display an image data?

Description

I was implementing a Go version of this ws-socket protocol and noticed that the subIDs and ChanIDs were getting mixed up and subscriptions not working properly with my implementation. Further investigation revealed that foxglove studio was not sending the channelID in the subscribe message as described in the spec of this protocol.

Here is a message from foxglove studio:

{\"op\":\"subscribe\",\"subscriptions\":[{\"id\":0}]}

As you can see it is missing the channelID.

My question is how can the websocket server know what channel this refers to? And am I missing something? Is this just an outdated documentation problem?

How can I receive a variable (generate by Variable Silder) in foxglove websocket mode from a foxglove python server?

Hi,
I am having trouble installing your library foxglove-websocket. Im on windows 11 and i used next commands:

• pip install foxglove-websocket
• conda install foxglove-websocket
• also tried installing it via Pycharm package manager

All of the above commands give out the same error:
PackagesNotFoundError: The following packages are not available from current channels: foxglove

Is there something that I am doing wrong or is Windows 11 not supported yet?

If a topic is unadvertised and then readvertised (can happen in live networks, when a task needs to be restarted), the server does not get a callback for subscribing to the data again from the python server library.

Steps to reproduce:

• Start eCAL Publisher "person"
• Start eCAL Foxglove Server
• Open Studio & Subscribe to "person" message
• Close Publisher
• Restart Publisher
  -> Topic is marked in Studio as available, but no data is received, since the server library did not reissue a subscription request.

Output from Server

2021-12-13 13:55:33,439: [INFO] Adding topics ['person']
2021-12-13 13:55:48,907: [DEBUG] Got message: {'op': 'subscribe', 'subscriptions': [{'id': 0, 'channelId': 0}]}
2021-12-13 13:55:48,907: [DEBUG] Client ('127.0.0.1', 50663) subscribed to channel 0
2021-12-13 13:55:48,908: [INFO] Subscribing to 0
2021-12-13 13:57:09,502: [INFO] Removing topics ['person']
2021-12-13 13:57:09,513: [DEBUG] Got message: {'op': 'unsubscribe', 'subscriptionIds': [0]}
2021-12-13 13:57:25,731: [INFO] Adding topics ['person']

Questions came up around sending 4 channels of raw images @ 15hz, ~8mb per frame (~1 Gbps per channel).

We should create a simple performance test to generate data using the Python (and/or JS) Websocket server, generating large quantities of random data, and see how fast we can get this into Studio and where the current bottlenecks are.

  hdlrs.subscribeHandler = [&](foxglove::ChannelId chanId, foxglove::ConnHandle) {
    std::cout << "first client subscribed to " << chanId << std::endl;
  };
  hdlrs.unsubscribeHandler = [&](foxglove::ChannelId chanId, foxglove::ConnHandle) {
    std::cout << "last client unsubscribed from " << chanId << std::endl;
  };

These handlers appear to use foxglove-websocket server behavior from a year ago - the current behavior is for the handler to be called once per client.

Description

• Version: master branch
• Platform: WSL2, docker is installed and service is started

Steps To Reproduce

I'm trying to build c++ version, so in cpp folder:
make build

docker compose build
docker: 'compose' is not a docker command.
See 'docker --help'
Makefile:5: recipe for target 'build' failed
make: *** [build] Error 1

Expected Behavior

build cpp project

ps

I have installed pip install docker-compose
docker-compose -version

/home/f/.local/lib/python3.6/site-packages/paramiko/transport.py:33: CryptographyDeprecationWarning: Python 3.6 is no longer supported by the Python core team. Therefore, support for it is deprecated in cryptography and will be removed in a future release.
  from cryptography.hazmat.backends import default_backend
docker-compose version 1.29.2, build unknown

Description
I am not totally sure this is a bug but as far as I can test i cannot make the handler parameterRequestHandler() be called. I modified the example code to add this handler. The only thing I added was a log message so i can confirm it was being called. For some reason it is never called.

Am I missing something? Was this ever tested since there is no example or tests for it?

• Version: releases/cpp/v1.2.0

Steps To Reproduce
Modify the protobuf test example_server_protobuf.cpp with this handler:

hdlrs.parameterRequestHandler = [&](const std::vector<std::string> &paramNames, const std::optional<std::string> &reqID, foxglove::ConnHandle hndl) {
    std::cout << "parameterRequestHandler() called!" << std::endl;
  };

Then connect via Foxglove studio and open the parameter panel. In the param server python example this would trigger the handler function but for some reason can't get the same behaviour on the c++ version

Description
I'm using foxglove-websocket in my project and found that it depends on a standalone ASIO library, so I had to set add_definitions(-DASIO_STANDALONE) in CMake. However, this seems to cause a conflict with the asio dependency in my project's cyberrt, resulting in a "Segmentation fault (core dumped)" error when I run my project.

• Version:
  CMake version: 3.21
  foxglove-websocket version: 1.0.0
  ASIO version: 1.10.8
• Platform:
  Ubuntu 18.04

Steps To Reproduce

I have created a minimal project to reproduce the issue and packaged the environment into a Docker container for easier reproduction. The Docker image is hosted on Docker Hub and can be pulled and run directly.

docker pull lucycat/foxglove_websocketpp_cyber_asio_conflict:0.1
docker run -it --ipc=host --network host lucycat/foxglove_websocketpp_cyber_asio_conflict:0.1 /bin/bash
// in docker
cd ~/ReproduceAsioConflict
mkdir -p build && cd build && rm -rf *
source /usr/local/setup.bash
cmake .. && make -j
./writer & 
./asio_conflict_test 

Expected Behavior
You'll find that it either hangs indefinitely or exits abruptly with a "Segmentation fault" error message. I hope you can help me resolve this issue, thank you!

Additionally, the source code used to reproduce this issue is also available on GitHub at this repository: https://github.com/FRAOTIAC/ReproduceAsioConflict. You can examine the code or clone the repository for further investigation.

• Update examples to use @foxglove/schemas

i installed the packages:

$ npm install @foxglove/ws-protocol
$ npm install ws

and added some code:

  import { FoxgloveClient } from "@foxglove/ws-protocol";
  import WebSocket from "ws";

  const address = 'ws://localhost:8765'

  const client = new FoxgloveClient({
    ws: new WebSocket(address, [FoxgloveClient.SUPPORTED_SUBPROTOCOL]),
  });

but im getting a compiler error on IWebSocket:

$ ./node_modules/.bin/tsc
src/main.ts:21:5 - error TS2322: Type 'WebSocket' is not assignable to type 'IWebSocket'.
  Types of property 'send' are incompatible.
    Type '{ (data: BufferLike, cb?: ((err?: Error | undefined) => void) | undefined): void; (data: BufferLike, options: { mask?: boolean | undefined; binary?: boolean | undefined; compress?: boolean | undefined; fin?: boolean | undefined; }, cb?: ((err?: Error | undefined) => void) | undefined): void; }' is not assignable to type '(data: string | ArrayBuffer | ArrayBufferView | Blob, options?: { fin?: boolean | undefined; } | undefined) => void'.
      Types of parameters 'data' and 'data' are incompatible.
        Type 'string | ArrayBuffer | ArrayBufferView | Blob' is not assignable to type 'BufferLike'.
          Type 'Blob' is not assignable to type 'BufferLike'.
            Type 'Blob' is missing the following properties from type 'Buffer': write, toJSON, equals, compare, and 95 more.

21     ws: new WebSocket(address, [FoxgloveClient.SUPPORTED_SUBPROTOCOL]),
       ~~

  node_modules/@foxglove/ws-protocol/dist/esm/src/FoxgloveClient.d.ts:23:9
    23         ws: IWebSocket;
               ~~
    The expected type comes from property 'ws' which is declared here on type '{ ws: IWebSocket; }'


Found 1 error in src/main.ts:21

I've tried using the same ws version as the example, but the example protocol library is very out of date.
An up to date working example would be greatly appreciated!

Description

Inside foxglove-websocket[examples] you might want to specify above which version protobuf is required, as I had an old version (3.19.4) and it didn't work.

For python protobuf server, it will throw error and tell you to pip install foxglove-websocket[examples], even if this was already executed. After installing latest protobuf (4.21.12) it works as expected.

• Version: Latest commit f13dded46401b1db166f2ea55bb50edfaccea0c1
• Platform: Windows

Steps To Reproduce
Install old protobuf version and try to run protobuf_server.py example.

Expected Behavior
To install correct requirements when you are installing them:)

Under some compilers a 'error: no matching function for call to ‘foxglove::websocket::Server::ClientInfo::ClientInfo()’ error is thrown. Adding a constructor to ClientInfo resolves this issue. Constructor that resolves the issue below:

ClientInfo(const std::string& name, const ConnHandle& handle) : name(name), handle(handle){};

At least the image-server example is still using a ros.sensor_msgs.CompressedImage schema. This should be changed to a foxglove.CompressedImage.

Description

Trying to run the python example as described in README.md raise an error :

ModuleNotFoundError: No module named 'foxglove_websocket.examples.proto.foxglove'

It's look like neither the proto schema not its protoc is include in the pip package : foxglove_websocket\examples\proto\ is empty

• Version: foxglove-websocket 0.0.8
• Platform: windows 11 / Python 3.10.2

Steps To Reproduce

• Create and start virtual env

  python -m venv myvenv
.\myvenv\Scripts\activate

• Follow README.md procedure

  pip install foxglove-websocket
pip install 'foxglove-websocket[examples]'

• Try to start sample
  python -m foxglove_websocket.examples.protobuf_server

• Following error occurs :

from foxglove_websocket.examples.proto.foxglove.SceneUpdate_pb2 import SceneUpdate
ModuleNotFoundError: No module named 'foxglove_websocket.examples.proto.foxglove'
Unable to import protobuf definitions; did you forget to run `pip install foxglove-websocket[examples]`?

Expected Behavior
Server should start w/o errors

Description
Sometimes, when closing studio, I get the following error on the websocket server:

Task exception was never retrieved
future: <Task finished name='Task-4' coro=<handle_messages() done, defined at D:\python\ecal_live.py:200> exception=InvalidState('Cannot write to a WebSocket in the CLOSING state')>
Traceback (most recent call last):
  File "D:\python\ecal_live.py", line 203, in handle_messages
    await server.send_message(
  File "D:\.venv-3.10\lib\site-packages\foxglove_websocket\server\__init__.py", line 168, in send_message
    await self._send_message_data(
  File "D:\.venv-3.10\lib\site-packages\foxglove_websocket\server\__init__.py", line 193, in _send_message_data
    await connection.send([header, payload])
  File "D:\.venv-3.10\lib\site-packages\websockets\legacy\protocol.py", line 666, in send
    await self.write_frame(True, OP_CONT, b"")
  File "D:\.venv-3.10\lib\site-packages\websockets\legacy\protocol.py", line 1185, in write_frame
    raise InvalidState(
websockets.exceptions.InvalidState: Cannot write to a WebSocket in the CLOSING state

• Version: python implementation, v0.0.7
• Platform: Windows

Steps To Reproduce
Close the websocket connection while sending data

Expected Behavior
The send_message operation should not throw an exception.

We should add an example server that sends Protobuf messages.

See foxglove/studio#5256 (comment) for more details

Steps To Reproduce

$ docker run -it --rm node:18 /bin/bash
root@066e73a8e175:/# npx @foxglove/ws-protocol-examples@latest sysmon
Need to install the following packages:
  @foxglove/[email protected]
Ok to proceed? (y) y

Expected Behavior
Examples work

Actual Behavior

(node:28) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
node:internal/deps/undici/undici:11118
    Error.captureStackTrace(err, this);
          ^

TypeError: Failed to parse URL from /root/.npm/_npx/d712c844522a0ed2/node_modules/wasm-lz4/wasm-lz4.wasm
    at Object.fetch (node:internal/deps/undici/undici:11118:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  [cause]: TypeError [ERR_INVALID_URL]: Invalid URL
      at new NodeError (node:internal/errors:393:5)
      at URL.onParseError (node:internal/url:565:9)
      at new URL (node:internal/url:645:5)
      at new Request (node:internal/deps/undici/undici:9472:25)
      at Agent.fetch2 (node:internal/deps/undici/undici:10291:25)
      at Object.fetch (node:internal/deps/undici/undici:11116:28)
      at fetch (node:internal/process/pre_execution:216:25)
      at instantiateAsync (/root/.npm/_npx/d712c844522a0ed2/node_modules/wasm-lz4/wasm-lz4.js:9:8977)
      at createWasm (/root/.npm/_npx/d712c844522a0ed2/node_modules/wasm-lz4/wasm-lz4.js:9:9587)
      at /root/.npm/_npx/d712c844522a0ed2/node_modules/wasm-lz4/wasm-lz4.js:9:10837 {
    input: '/root/.npm/_npx/d712c844522a0ed2/node_modules/wasm-lz4/wasm-lz4.wasm',
    code: 'ERR_INVALID_URL'
  }
}

Hi,

I'm trying to write some python code to in examples.protobuf_server.py

To show my data in the 3D pane, I think I need to create a foxglove.PointCloud message, but I'm stuck here.

my python code to create the message is like this:

empty_pose = Pose_pb2.Pose(
            position=Vector3_pb2.Vector3(x=0,y=0,z=0), orientation=Quaternion_pb2.Quaternion(x=0,y=0,z=0,w=1)
        )
point_cloud = PointCloud_pb2.PointCloud(
                timestamp=timestamp,
                frame_id="point_cloud",
                pose=empty_pose)

then I don't know how to create the other 3 protobuf fields:

  // Number of bytes between points in the `data`
  fixed32 point_stride = 4;

  // Fields in the `data`
  repeated foxglove.PackedElementField fields = 5;

  // Point data, interpreted using `fields`
  bytes data = 6;

expecailly for foxglove.PackedElementField, it's very complicated.

Any sample code to show how to create a PackedElementField or the whole PointCloud message? otherwise I'm afraid that I need to spend several days to try and err and try again.

On this page https://github.com/foxglove/ws-protocol/blob/main/docs/spec.md:

• If you click on the link to "Message Data" in the TOC, it takes you to the client message data, not server message data.

• Additionally, the client message data op is listed under a heading called "JSON Messages". The heading called "Binary Messages" doesn't include the client message data.

• It looks like Service Call Request and Time have the same opcode (0x02).

• The Service Call Request heading is too small (wrong level)

The spec says:

A client may only have one subscription for each channel at a time.

However, our reference implementations allow this by keeping a mapping from channel id to multiple subscription ids for each client:

We should provide example code for using Protobuf encoding in C++.

This will also require importing or adding our own base64 encoding implementation.

Enables: foxglove/community#354

Including sessionId sent by server on opening connection allows client to understand context and if the connection is a re-connection from a dropped context, or if it is a new session connecting. We will then be able to clear state in the client when connecting to a new context, but retain state when reconnecting a dropped connection.

Context: Customer is currently reconnecting to a websocket in a different context and the state is being preserved leading to incorrect results. They would like the state to be cleared when reconnecting to the WS in a new context.