5 ms·

> A silly question: do you forsee any issues getting Cap’n Proto 0.8 to work over a completely locked down Docker environment that only allows HTTPS proxy as th

> A silly question: do you forsee any issues getting Cap’n Proto 0.8 to work over a completely locked down Docker environment that only allows HTTPS proxy as the connection between nodes that use Cap’n Proto RPC? If it supports WebSocket, it should be relatively easy to layer Cap'n Proto RPC on top of that. Alternatively, some proxies allow full-duplex HTTP (request and response bodies streaming simultaneously), which could also be enough to bootstrap a connection on top of -- but in practice that tends to run into a lot of problems. Otherwise, that's tough. HTTP is fundamentally a one-way, FIFO request-response protocol, whereas Cap'n Proto is multi-directional and asynchronous. Starting a separate HTTP connection for each call -- with connections initiated in both directions -- would be pretty ugly and have lots of issues with synchronization and routing. > PS: Thoughts on why Cap’n Proto did not win over MessagePack? MessagePack had a better JS implementation? Is it the convenience of not needing to define a schema when using MessagePack vs Cap’n Proto schema requirement? I don't really consider MessagePack a direct competitor to Cap'n Proto. It's more of a competitor to JSON. Schema-driven vs. non-schema-driven changes everything about how you use a serialization. A more apples-to-apples comparison in Protobuf. Protobuf is much more popular for a simple reason: It has had a lot more engineering investment, leading to mature implementations in more languages and lots of great tooling that capnp doesn't have (yet). No amount of clever design can beat that.

anderspitman 7y ago
> If it supports WebSocket, it should be relatively easy to layer Cap'n Proto RPC on top of that. How would the new streaming functionality be implemented over WebSockets? WS has no flow control. You can check bufferedAmount but I found it to be fairly useless[0]. Maybe it's improved in the last 1.5 years or I was using it wrong. > HTTP is fundamentally a one-way, FIFO request-response protocol, whereas Cap'n Proto is multi-directional and asynchronous. Starting a separate HTTP connection for each call -- with connections initiated in both directions -- would be pretty ugly and have lots of issues with synchronization and routing. I think you could get a long way using HTTP/2 and server-sent events. [0]: https://github.com/websockets/ws/issues/492 https://github.com/websockets/ws/issues/492 EDIT: added link to bufferedAmount issue
- kentonv 7y ago
  > How would the new streaming functionality be implemented over WebSockets? WS has no flow control. Sure it does. WS is just a framing protocol on top of a regular TCP connection. Though it sounds like you're not talking about the protocol so much as the JavaScript API, which perhaps doesn't give you enough visibility into the underlying TCP socket state. But a BBR-like algorithm could still work. Basically (massively oversimplified): 1) Determine the connection latency based on the fastest response you've seen. 2) Determine the connection throughput by tracking the highest throughput you've ever seen. 3) Set your window size to be a little bit more than latency * throughput. This "should" saturate the connection with just a little bit of buffering. If it doesn't saturate the connection, then your measured throughput will go up until it does. This way there is no need to ask the OS or browser to tell you how much is buffered... Disclaimer: I have yet to actually implement something like this. Obviously, it gets tricky in the details.
  - anderspitman 7y ago
    > Sure it does. WS is just a framing protocol on top of a regular TCP connection. Though it sounds like you're not talking about the protocol so much as the JavaScript API, which perhaps doesn't give you enough visibility into the underlying TCP socket state. Every WS implementation I've ever seen is nonblocking on both sides. Are you aware of any that aren't? I'm not even sure the spec allows for that. But yes you are correct that you can implement more advanced algos on top. EDIT: Sounds like blocking implementations do exist, but unfortunately I'm constrained to a browser environment, and all the browsers are nonblocking.
    - zenhack 7y ago
      off the top of my head https://godoc.org/golang.org/x/net/websocket https://godoc.org/golang.org/x/net/websocket has a synchronous read/write api
      - anderspitman 7y ago
        Does that block until messages are actually transferred, or just shove them in a golang buffer and return? Now that you mention it I feel like maybe I have seen blocking implementations in golang and Python a while back, which would make sense.

anderspitman 7y ago

> If it supports WebSocket, it should be relatively easy to layer Cap'n Proto RPC on top of that. How would the new streaming functionality be implemented over WebSockets? WS has no flow control. You can check bufferedAmount but I found it to be fairly useless[0]. Maybe it's improved in the last 1.5 years or I was using it wrong. > HTTP is fundamentally a one-way, FIFO request-response protocol, whereas Cap'n Proto is multi-directional and asynchronous. Starting a separate HTTP connection for each call -- with connections initiated in both directions -- would be pretty ugly and have lots of issues with synchronization and routing. I think you could get a long way using HTTP/2 and server-sent events. [0]: https://github.com/websockets/ws/issues/492 https://github.com/websockets/ws/issues/492 EDIT: added link to bufferedAmount issue

kentonv 7y ago
> How would the new streaming functionality be implemented over WebSockets? WS has no flow control. Sure it does. WS is just a framing protocol on top of a regular TCP connection. Though it sounds like you're not talking about the protocol so much as the JavaScript API, which perhaps doesn't give you enough visibility into the underlying TCP socket state. But a BBR-like algorithm could still work. Basically (massively oversimplified): 1) Determine the connection latency based on the fastest response you've seen. 2) Determine the connection throughput by tracking the highest throughput you've ever seen. 3) Set your window size to be a little bit more than latency * throughput. This "should" saturate the connection with just a little bit of buffering. If it doesn't saturate the connection, then your measured throughput will go up until it does. This way there is no need to ask the OS or browser to tell you how much is buffered... Disclaimer: I have yet to actually implement something like this. Obviously, it gets tricky in the details.
- anderspitman 7y ago
  > Sure it does. WS is just a framing protocol on top of a regular TCP connection. Though it sounds like you're not talking about the protocol so much as the JavaScript API, which perhaps doesn't give you enough visibility into the underlying TCP socket state. Every WS implementation I've ever seen is nonblocking on both sides. Are you aware of any that aren't? I'm not even sure the spec allows for that. But yes you are correct that you can implement more advanced algos on top. EDIT: Sounds like blocking implementations do exist, but unfortunately I'm constrained to a browser environment, and all the browsers are nonblocking.
  - zenhack 7y ago
    off the top of my head https://godoc.org/golang.org/x/net/websocket https://godoc.org/golang.org/x/net/websocket has a synchronous read/write api
    - anderspitman 7y ago
      Does that block until messages are actually transferred, or just shove them in a golang buffer and return? Now that you mention it I feel like maybe I have seen blocking implementations in golang and Python a while back, which would make sense.