5 ms·

HTTP accomplishes all of our design constraints via REST and long-lived streaming connections. It is a very reliable, mature protocol, and the security and perf

HTTP accomplishes all of our design constraints via REST and long-lived streaming connections. It is a very reliable, mature protocol, and the security and performance are very well understood. Also, if we invented a new binary protocol, users wouldn't be able to host their Tent servers on easy-to-use platforms like Heroku. Developers may implement other protocols in the future, but we are targeting HTTP as an accessible starting point. We are definitely anticipating heavy mobile use, both through mobile web apps as well as native. There will eventually be iOS and Android frameworks to handle all of the communication with Tent servers.

mbreese 14y ago
You wouldn't have to invent a new binary protocol, a simple text protocol can work wonders (see: memcached or Redis). I'd personally look more towards SMTP for inspiration (not security wise, of course). Since you're going to mainly be passing messages back and forth, not resources. You really should also think about two separate protocols... one server-to-server, the other server-to-client. At least, that's how I've been working on it :)
- danielsiders 14y ago
  Actually, we do support passing resources back and forth and for a lot of use cases doing so saves quite a few round trips in the long run. Our protocol has two distinct parts, one server-server, the other server-app. It's just easier to manage a single "API" than having some support server-server but not server-app--we're hoping to avoid ecosystem fragmentation into those who don't want to support apps or vice versa.
flatline3 14y ago
HTTP is a huge, hefty, inefficient and complex protocol whose only advantage is that HTML/JS supports it by default. Arguments that 'websockets' solve this are ridiculous in the face of the fact that we can just use 'sockets', like we always have. WebSockets are a work-around for the constraints of the browser. As a mobile/desktop/server engineer, I would love the opportunity to work with other server-side teams that aren't wedded to the web/HTTP via historical accident and thus don't force us to use HTTP.
- TazeTSchnitzel 14y ago
  WebSockets also have the advantage that they pass through corporate firewalls and open wifi networks, as well as many proxies, as they masquerade as HTTP traffic. And a nicer frames mechanic than raw socket, something I love. (nowhere near as low-level, but for me it's essentially stateful UDP that's reliable, i.e. TCP except with datagrams)
  - flatline3 14y ago
    Corporate firewalls are the general boogieman, but in reality, I haven't seen evidence that they're much more than that. To test this, we implemented fallback-to-HTTPS behavior in a very widely used previously non-HTTP client. We then observed the number of clients that failed to connect via our custom protocol, but succeeded in falling back to HTTPS. The numbers were negligible. It's ridiculous that we'd seriously believe that we can't trust that TCP works on the internet. We joke about it being the "interweb", but I see no reason to sow fear, uncertainty, and doubt, and thus and actually turn the interweb into reality.
    - TazeTSchnitzel 14y ago
      Perhaps, but open wifi often only allows 443 and 80.
      - flatline3 14y ago
        That also breaks IMAP(S), SMTP(S), Jabber, AIM, and a slew of other applications. I don't see that we should model the internet architecture on bad technical choices made on a limited number of open wifi networks. Or, we just frame our standard protocol over websockets as an (unfortunate) fallback, if it ever is revealed to be a real problem.
      - ynniv 14y ago
        Port numbers are not protocols.
        14y ago

mbreese 14y ago

You wouldn't have to invent a new binary protocol, a simple text protocol can work wonders (see: memcached or Redis). I'd personally look more towards SMTP for inspiration (not security wise, of course). Since you're going to mainly be passing messages back and forth, not resources. You really should also think about two separate protocols... one server-to-server, the other server-to-client. At least, that's how I've been working on it :)

danielsiders 14y ago
Actually, we do support passing resources back and forth and for a lot of use cases doing so saves quite a few round trips in the long run. Our protocol has two distinct parts, one server-server, the other server-app. It's just easier to manage a single "API" than having some support server-server but not server-app--we're hoping to avoid ecosystem fragmentation into those who don't want to support apps or vice versa.

flatline3 14y ago

HTTP is a huge, hefty, inefficient and complex protocol whose only advantage is that HTML/JS supports it by default. Arguments that 'websockets' solve this are ridiculous in the face of the fact that we can just use 'sockets', like we always have. WebSockets are a work-around for the constraints of the browser. As a mobile/desktop/server engineer, I would love the opportunity to work with other server-side teams that aren't wedded to the web/HTTP via historical accident and thus don't force us to use HTTP.

TazeTSchnitzel 14y ago
WebSockets also have the advantage that they pass through corporate firewalls and open wifi networks, as well as many proxies, as they masquerade as HTTP traffic. And a nicer frames mechanic than raw socket, something I love. (nowhere near as low-level, but for me it's essentially stateful UDP that's reliable, i.e. TCP except with datagrams)
- flatline3 14y ago
  Corporate firewalls are the general boogieman, but in reality, I haven't seen evidence that they're much more than that. To test this, we implemented fallback-to-HTTPS behavior in a very widely used previously non-HTTP client. We then observed the number of clients that failed to connect via our custom protocol, but succeeded in falling back to HTTPS. The numbers were negligible. It's ridiculous that we'd seriously believe that we can't trust that TCP works on the internet. We joke about it being the "interweb", but I see no reason to sow fear, uncertainty, and doubt, and thus and actually turn the interweb into reality.
  - TazeTSchnitzel 14y ago
    Perhaps, but open wifi often only allows 443 and 80.
    - flatline3 14y ago
      That also breaks IMAP(S), SMTP(S), Jabber, AIM, and a slew of other applications. I don't see that we should model the internet architecture on bad technical choices made on a limited number of open wifi networks. Or, we just frame our standard protocol over websockets as an (unfortunate) fallback, if it ever is revealed to be a real problem.
    - ynniv 14y ago
      Port numbers are not protocols.
      - 14y ago