Issue with custom transport for Client-Server binary protocol

[akshaykmr]

This is probably something off on my end, and I'll try printing and debugging with official examples to understand why. But just in case it's something obvious:

I'm integrating a custom transport for the client-server binary protocol instead of using the provided WebSocket client and server. On the JavaScript client, I have my own send_message(data: Uint8Array), and on the Python server, I receive the bytes and pass them to session.handle_request(data) .

However, the server responds with an "Unhandled request type" error, and I can't figure out what I'm doing wrong.

Here's the flow:

1. I create the Client, giving it my send_message implementation.
2. On client.init(), the sent message I log on the frontend is:

Uint8Array(4) [ 208, 53, 21, 0 ]

3. On the server, I receive the bytes. when printing list(data), I have the same byte sequence:

[208, 53, 21, 0]

• Despite the bytes appearing identical, the server session.handle_request(data) rejects the message with following reply:

  b'\x92\x03\x1a\n\x18Unhandled request type 2'
  

I'm using Perspective 3.4.1 on both the client and server.

Does anyone have insights into what might be going wrong? Could there be additional encoding/decoding steps I'm missing?

PS: Perspective seems like an awesome library. I discovered it on Hacker News recently, and it consumed my whole weekend! Hopefully, I can build something cool to share one day ^_^

[texodus]

I would need to see the code. From your description, it appears your implementation is correct (there is no additional encoding required), the error message however indicates a malformed request. I think this byte sequence is not correct as well.

Documentation for this feature (custom transport) is still a WIP, and there are a few sharp edges it is easy to get cut on. Most importantly, the Uint8Array which backs the message injected to send_message is actually a direct view onto the WASM heap, which helps us avoid an otherwise needless copy in most cases - ergo if you do not read this message immediately within the scope of the send_message callback, you may read wrong data or even an already GC-ed page (though in the altter case, the underlying ArrayBuffer will be detached throwing a clear error). This is especially tricky in the context of asynchronous handlers which may not be evaluated right away.

[akshaykmr]

if you do not read this message immediately within the scope of the send_message callback, you may read wrong data or even an already GC-ed page

Aha, this was it. Got it working on first try after making the changes.

in brief, what I had before

const sendMessage = async (data: Uint8Array) => {
    await this.channel;  // my transport is ready
   
   // then sending the bytes
}

Now I have:

const sendMessage = async (data: Uint8Array) => {
  const buffer = data.slice().buffer;
  const bytes = new Uint8Array(buffer);

  const channel = await this.channel;

  // send the bytes
}

The byte sequence on client.init is now consistently [8, 1, 26, 0]. No changes on the backend, and it replies correctly which resolves the client.init() Promise on the frontend.

Thanks so much! I can now play around with the viewer.