Can this library be used with WICG Direct Sockets for a WebTransport server?

[guest271314]

WICG Direct Sockets exposes TCPServerSocket , UDPSocket, and TCPSocket in an Isolated Web App, on Chromium-based browsers.

I've successfully created an HTTP and WebSocket server using only JavaScript shipped in the browser - other than the above interfaces exposed in an IWA.

Can this library be used with WICG Direct Sockets for a WebTransport (HTTP, HTTP/2, HTTP/3, h2c) server?

[martenrichter]

Currently, it is impossible as only node.js sockets are used, and the C++ part for http/3 needs to be compiled with wasm.
The same is true for the http/2 (and WebSocket server); here, only the node.js socket functions are used.
An extension to this use case is possible in principle, but it is not on my agenda as it does not overlap with my use cases.

[guest271314]

I think it's possible to simply rewrite the Node.js API parts to use Web API's and use WASI-SDK to produce WASM from C++, or convert the C++ to AssemblyScript then the WASM asc produces.

Thanks.

[martenrichter]

No I do not think that it is so simple. For WebTransport over Http/2 or WebTransport you would need to rewrite large parts that node.js HTTP, http/2 servers provide.
For http/3, it may be simpler as only the socket part is used from node.js, but then you need to compile with emscripten and rewrite the interface part of the C++ part, which currently uses an API to interface with node.js to interface with emscripten; this is a larger task.

[guest271314]

No I do not think that it is so simple. For WebTransport over Http/2 or WebTransport you would need to rewrite large parts that node.js HTTP, http/2 servers provide.

I've done that before, more than once. E.g., rewriting wbn to use Web Cryptography API and substituting Uint8Array, et al. for Buffer; https://github.com/guest271314/direct-sockets-http-ws-server?tab=readme-ov-file#buildrebuild-wbn-bundlejs-from-webbundle-pluginspackagesrollup-plugin-webbundlesrcindexts-with-bun. The code was originally written for Node.js exclusively. I modified the code to work using node, deno, and bun.

For http/3, it may be simpler as only the socket part is used from node.js, but then you need to compile with emscripten and rewrite the interface part of the C++ part, which currently uses an API to interface with node.js to interface with emscripten; this is a larger task.

I've compiled the same algorithm to WASM from C++, C, Rust using WASI-SDK or clang, JavaScript using Facebook's Static Hermes with WASI-SDK and/or Emscripten, Bytecode Alliance's Javy; and compiled node-http2 module that was merged into Node.js to a bundle that can be used with node, deno, or bun using bun build.

I generally make an effort to write runtime agnostic, and when possible language agnostic code that can be run in different environments.

Sockets are generally the same between Node.js, Deno, Bun, and the browser implementation in TCPServerSocket, TCPSocket, and UDPSocket.

Right now I'm trying to figure out what the headers look like. Then I can try to do a HTTP/1.1 to HTTP/2 Upgrade, first. Or dive in to QUIC over UDP. I looked at Deno's implementation, that works to an appreciable degree, though that also has Deno-specific traits https://gist.github.com/guest271314/c1974f24fff86fe4708f901651be8079.

[guest271314]

Another avenue I'm working on is using Chrome's built-in full-duplex streaming over fetch() between a ServiceWorker and a WindowClient or Client. That is the only browser implementation of HTTP/2 full-duplex streaming in a browser where fetch() does fulfill to a Response before then response is completed from the remote server. E.g., using an extension to stream from any arbitrary Web site into the single connection HTTP/2 connection between a WindowClient and a ServiceWorker on Chromium-based browsers

addEventListener("fetch", async (e) => {
  console.log(e.request.url, e.request.destination, e.clientId);
  if (e.request.url.includes("stream")) {
    e.respondWith(
      new Response(
        e.request.body
          .pipeThrough(new TextDecoderStream())
          .pipeThrough(
            new TransformStream({
              async start() {
                // getClientState(e.clientId);
                if (globalThis.port === null) {
                  readable = new ReadableStream({
                    start: (_) => {
                      return controller = _;
                    },
                    cancel(reason) {
                      console.log(reason);
                    },
                  });
                  reader = readable.getReader();
                  port = chrome.runtime.connectNative(
                    chrome.runtime.getManifest().short_name,
                  );
                  port.onMessage.addListener((message) => {
                    controller.enqueue(encoder.encode(message));
                  });
                  port.onDisconnect.addListener((e) => {
                    console.log(e);
                    if (chrome.runtime.lastError) {
                      console.log(chrome.runtime.lastError);
                    }
                    controller.close();
                    port = readable = controller = null;
                  });
                }
              },
              async transform(value, c) {
                console.log(value);
                port.postMessage(value);
                const { value: message, done } = await reader.read();
                console.log(message, done);
                c.enqueue(message);
              },
              flush() {
                console.log("flush");
              },
            }),
          ),
      ),
    );
  }
});

In DevTools in an arbitrary Web page

async function nativeMessageStream(u, rs) {
  function removeFrame() {
    const frames = document.querySelectorAll("[src^=chrome]");
    frames.forEach((w) => {
      w.remove();
    });
    return document.querySelectorAll("[src^=chrome]").length;
  }

  async function generateIdForPath(path) {
    return [
      ...[
        ...new Uint8Array(
          await crypto.subtle.digest("SHA-256", new TextEncoder().encode(path)),
        ),
      ].map((u8) => u8.toString(16).padStart(2, "0")).join("").slice(0, 32),
    ].map((hex) => String.fromCharCode(parseInt(hex, 16) + "a".charCodeAt(0)))
      .join("");
  }

  const url = new URL(
    `chrome-extension://${await generateIdForPath(u)}/transferableStream.html`,
  );
  return new Promise((resolve) => {
    function handleMessage(e) {
      console.log(e);
      if (e.origin === url.origin) {
        if (e.data instanceof ReadableStream) {
          resolve({
            readable: e.data.pipeThrough(
              new TransformStream({
                transform(value, c) {
                  c.enqueue(value);
                },
                flush() {
                  removeEventListener("message", handleMessage);
                  console.log(removeFrame());
                },
              }),
            ),
            transferableWindow,
          });
        } else {
          e.source.postMessage(rs, "*", [rs]);
        }
      }
    }
    addEventListener("message", handleMessage);
    const transferableWindow = document.createElement("iframe");
    transferableWindow.style.display = "none";
    transferableWindow.name = location.href;
    transferableWindow.src = url.href;
    transferableWindow.addEventListener("load", (e) => {
      console.log(e);
    });
    document.body.appendChild(transferableWindow);
  }).catch((err) => {
    throw err;
  });
}

var { readable: r, writable: w } = new TransformStream();
var writer = w.getWriter();
var encoder = new TextEncoder();
var { readable, transferableWindow } = await nativeMessageStream(
  "/home/user/half_duplex_stream",
  r,
);

Thereafter

await writer.write(encoder.encode("Streaming request");

which is enqued into the upload stream, and the response is sent back to the WindowClient in a single connection. I have kept ServiceWorkers active for over 48 hours (technically the connection can be indefinite https://plnkr.co/edit/bK1BfoSgjFUDwkIV?preview, and full-duplex, just using WHATWG Fetch) on a single HTTP/2 connection using this approach https://github.com/guest271314/persistent-serviceworker/tree/main/readablestream-fetch-respondwith.

[martenrichter]

Here are some pointers for http/3:
https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/http3wtsessionvisitor.cc
https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/http3wtsessionvisitor.h
https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/http3wtstreamvisitor.cc
https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/http3wtstreamvisitor.h
https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/http3server.h
https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/http3client.h
https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/napialarmfactory.cc
https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/socketjswriter.cc
https://github.com/fails-components/webtransport/blob/master/transports/http3-quiche/src/librarymain.cc
all these use NAPI for node binding and would need a replacement, if compiled to wasm. (Including the mechanims for alarams and napialarmfactory and sockerjswriter.cc.

and here for http/2 (and webtransport over websocket for the server side):
https://github.com/fails-components/webtransport/blob/master/main/lib/http2/node/client.js
https://github.com/fails-components/webtransport/blob/master/main/lib/http2/node/server.js

[martenrichter]

And please note, that currently browser support as client only Webtransport over http/3 and via the polyfill of the lib Webtransport over websocket.

[guest271314]

I'll see what kind of damage I can do. I already re-wrote somebody elses Node.js WebSocket work to runtime agnostic JavaScript. Thanks.

[guest271314]

@martenrichter I have a question about WebSocket if you have the time and it's appropriate to ask here. Thanks.

[martenrichter]

Sure.

[guest271314]

I'm trying to figure out why the WebSocket server code I adapted (https://github.com/guest271314/direct-sockets-http-ws-server/blob/main/assets/script.js#L1-L193, https://github.com/guest271314/direct-sockets-http-ws-server/blob/main/assets/script.js#L262-L291) from here https://gist.github.com/robertrypula/b813ffe23a9489bae1b677f1608676c8 stops sending back messages after around the second message.

E.g., something like this should work with the above implementation. Instead, only two (2) messages are sent back to the browser

var wss = new WebSocketStream("ws://0.0.0.0:44818");
console.log(wss);
wss.closed.catch((e)=>{console.log(e)});
var {readable, writable, } = await wss.opened.catch(console.error);
var writer = writable.getWriter();
var abortable = new AbortController();
var {signal, } = abortable;
// .pipeThrough(new TextDecoderStream())
var pipe = readable.pipeTo(new WritableStream({
  start(c) {
    console.log("Start", c);
  },
  async write(v) {
    console.log(v);
  },
  close() {
    console.log("Socket closed");
  },
  abort(reason) {
    console.log({ reason });
  },
}), {
  signal,
}, ).then(()=>console.log("Done")).catch((e)=>console.log(e));

var encoder = new TextEncoder();
var decoder = new TextDecoder();
var encode = (text)=>encoder.encode(text);
for (let i = 0; i < 10; i++) {
  await writer.write(encode("X".repeat(4096)));
  await writer.ready;
}

[guest271314]

The real test: Do what I can do using WebTransport with echoing 7 MB

var data = new Uint8Array(1024**2*7);
for (let i = 0; i < data.length; i += 1024*4) {
  await writer.write(data.subarray(i, i + 1024*4));
  await writer.ready;
}

That works using Deno's builtin WebSocket server. So there must be an issue with the implementation I adapted for use in the browser.

[guest271314]

I'm pretty sure this is the totality of the runtime agnostic implementation https://gist.github.com/guest271314/735377527389f1de6145f0ac71ca1e86.

[martenrichter]

It's hard to say from the code. I would probably add a lot of console.log to the server code and frame code.
What looks suspicious is that the remaingBytes are only used for the one chunk of data coming from the socket. So I think you are discarding data and losing sync in the websocket frames. But I may have missed something.