Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

JSRPC: Support capnp-over-http for external server bindings #1757

Merged
merged 3 commits into from
Mar 5, 2024
Merged

JSRPC: Support capnp-over-http for external server bindings #1757

merged 3 commits into from
Mar 5, 2024

Commits on Mar 5, 2024

  1. JSRPC: Support capnp-over-http. 

    Incoming listen sockets and outgoing ExternalService bindings can now both be configured to send/receive a special HTTP CONNECT request to open a Cap'n Proto connection. It is then possible to use JS RPC over such a binding.

Thus, separate workerd intances can be configured to speak RPC to each other, even over a network.
    @kentonv
    kentonv committed Mar 5, 2024
    Configuration menu
    Copy the full SHA
    04bb92c View commit details
    Browse the repository at this point in the history

  2. JSRPC: Add suport for "loopback socket" during workerd test. 

    A socket can be declared to listen on an address like `loopback:name`, and an ExternalService can connect to it. This namespace exists only in-process.

This will allow us to test RPC while invoking the whole network stack.
    @kentonv
    kentonv committed Mar 5, 2024
    Configuration menu
    Copy the full SHA
    9453b08 View commit details
    Browse the repository at this point in the history

  3. JSRPC: Extend js-rpc-test to test over real sockets, and fix a bug. 

    Without creating a PendingEvent for every incoming RpcTarget, the IoContext may be canceled prematurely, because the system thinks that there's no way more events could arrive.

This problem didn't come up when using direct service bindings because the PendingEvent system does not cancel the IoContext until the thread's event loop has been emptied, just before going back to the OS to wait for I/O. With local service bindings, the communications back and forth between the services all happens entirely in the local event loop without requiring any I/O, so the test completes before the PendingEvent system can kick in and cause a problem. When we use a real socket, communications between Workers requires actual OS I/O, so the PendingEvent has a chance to do its thing.
    @kentonv
    kentonv committed Mar 5, 2024
    Configuration menu
    Copy the full SHA
    bf992cf View commit details
    Browse the repository at this point in the history