We're working on additional refinements to the release process to minimize disruptions.

(I work at CloudFlare.)

In our case, we keep a buffer of the last N websocket messages sent to the client, and when the client reconnects, it sends the last sequence id that the client saw, and the server catches it up.

https://discordapp.com/developers/docs/topics/gateway#resumi...

CF WS support means I will no longer have to keep around a separate, direct-to-server (sub)domain around for my WebSockets projects, and this also means goodbye to any websockets-related SSL certificate hassle in this regard.

You can have different subdomains map to the same server IP address so I can't think of a reason why this would be a problem. That's what we did for https://baasil.io/

It's still nice though from the point of view that you no longer have to think about it. A lot of users wrongly assumed that you couldn't have Cloudflare AND WebSockets but you always could. At least now there won't be any confusion since it will just work by default.

Also, now that CF supports WebSocket as part of their offering, maybe they will also offer features like WebSocket rate limiting and such (for protecting against DoS)... And that would be useful.

Cloudflare can't protect you from DOS attacks if the attacker knows the IP address of your origin.

Nope.

Similar to other companies I give up a good control of my life to, Cloudflare essentially becoming a new internet backbone is ever so slightly terrifying.

Cloudflare itself is a "single point of failure." (Though massively unlikely with their incredible infra).

Cloudflare could shut off all of it's servers, or it's nameservers could go haywire, and there would be a massive internet outage. Much like when AWS goes down.

It's not clear to me what a "low" or "high" volume of connections is, and if that is number of connections or throughput.

[Edit: actually, we're not switching since only the business plan provides "Advanced DDoS protection - layer 3 and 4", which was why we are using CloudFlare in the first place.]

Allegedly, previous to WS, the only alternatives were flash and polling! Except that long-polling isn't really polling in any meaningful sense (they very clearly describe polling that isn't so-called long-polling), and in particular doesn't have the latency-vs-bandwidth tradeoff and impact that actual polling has.

Allegedly, WS are "exponentially more efficient"! Except that they're not, they're more efficient by a constant factor.

Allegedly, the range of bandwidth saving is 99.8% to 99.9%! Except that obviously if you're passing enough data around in few enough responses, the bandwith savings could be more like 5% or 10%, and I find it hard to believe that typical uses actually save over 50%.

I sure do think web sockets are sweet, but wouldn't it be nice if there was some way to hold liars accountable?

Connections are very very cheap to maintain, and very very expensive to build up and break down. Even in environments with load balancers, stateful firewalls, etc., it is much easier to keep a socket open than it is to create a new one.

If you're doing any kind of realtime data, websockets are the way to go. It is way, way easier to do stream processing and deal with backpressure than it is to have a gigantic number of clients doing http polling.

When Cloudflare mentions that websockets haven't had a gigantic uptake, I don't wonder if it's because Amazon's ELB doesn't support them and people don't want to roll their own haproxy solution.

What they -don't- support at that layer is sticky sessions, ip hashing, or similar; when a connection drops, you could reconnect to -any- instance behind the ELB. You have to engineer for that.

They also don't support Socket.IO if you have more than one instance behind the ELB (as, presumably, you do). This is because Socket.IO doesn't just open a websocket connection, and on failure fall back to something else; instead, it makes a REST call to the backend to see what connections it supports, then makes the websocket call. Both of these calls have to hit the same Socket.IO instance, because they're tied together with a session identifier. If they hit separate ones, then Socket.IO rejects the websocket, because that instance has never seen that session identifier before. But this is particular to Socket.IO's implementation, and not websockets themselves.

- you can halves the number of DB requests by 2 because refreshing is done by message passing half of the time instead of making a new requets trigerring DB calls. - cache invalidation is pro-active, and linked to events instead of just time. - you can have much more live stuff: settings, routing, configuration in general. You only need to load it once from your store, after that, any update is propagated. A CMS becomes cheap. - making clients talk to each others is easy. - websocket don't have CORS issues. You client code can query your live site, or a local backend, and synchronize both. - you can use the same canal of communication between your user clients and internal (micro-services) clients. The architecture becomes simpler. - if you have a heavy authentication process and complex sessions data, they can now be store with the persistent connection instead of being queried for every request.

Of course, not all that is enabled by default. You need to use some framework such as crossbar.io or meteorjs to get those benefits for free. Yet, it's very sweet.

How many is "Important to your operations"? If there's no number, it's hard to predict if I'll need Business or Enterprise.

Nvm I have a central Redis server with SocketIO.

And do CF limits transfer rate like 128k/sec for free plans? If yes then it is just an experimental toy anyway.

Ok, I know you can send data, but you can do that with HTTP/Ajax + SSE.

Because of CloudFlare's position regarding Tor users, along with the erroneous idea that an identity is an IP address, these changes do nothing for the Tor user and developer community at large.

Tor is used for more than just routing around censorship. I use it to create a seamless network of all my computers all via hidden services. So every machine has a "hidden service domain name" of [hash].onion . Knowing all the hashes of my machines means I can then use all my machines as a computing cloud.

I've also figured out how to seamlessly handle DNS resolution of onion addresses at the resolver level, meaning all Linux programs that can handle DNS names can also handle Onion names. Effectively that means that tools like Puppet and Chef work over Tor as well.

Cloudflare serves to undo and retard growth of Tor and I2P (which gets much less attention). And there are definite positives of using Tor... along with anti-censorship and strong anonymity claims.

I have a site. Because the site is... disparaging to political figures, I want to run behind Tor as a hidden service. Now, CloudFlare is good at their core business, so I hire them to cache my .onion site for mass consumption. It also defends my .onion site from being slashdotted/reddit hug of death/HNbombed.

All the better if fellow Tor users access my site: I want people to consume/use my site. That's why it's published.

And here is CloudFlare, destroying Tor user's capability of using any site that hires CloudFlare. It's a completely ridiculous situation, and a horrid solution they ascribe to that does nobody any favors.

Now, they do have some valid reasons. And there can also be technological ways to solve it without shitcanning every Tor user.

1. Tarpit defense. Slow down connections that show 'harassing behaviors' No you don't need to see that webpage 100 times in a second.

2. Offer a CloudFlare.onion hidden service. There's no reason they can't get into Tor HS as well. Facebook already is.

3. Limit bandwidth to known Tor exit nodes. Don't block.

CloudFlare is not blocking exit nodes because of volumetric DDoS attacks. That's not really viable over Tor anyway. It's mostly to block comment spam, crawlers and vulnerability scans (e.g. SQLi), which is unfortunately often done through Tor in automated ways.

Also: Website owners using CloudFlare can whitelist Tor traffic if they so chose.

I don't see how 2) would change anything with regards to the blocking situation. All the aforementioned problems would still apply, the only difference would be that they'd lose the IP address as an identifier, making it even harder to filter malicious traffic. I'm not against CloudFlare implementing something like that, but I fail to see the relevancy and I do wonder if tunneling all hidden service traffic for a site through a centralized service (which needs access to the plaintext in order to do any kind of caching or filtering) is a good idea for a project like Tor.

went looking through your github and blog for some code andor a writeup

any plans to post? god of magic :p

Just install Tor as you normally would, and turn on Hidden Services from port 22 to port 22 (for SSH). Keep track of the generated Tor onion hostname when you restart with Hidden Services enabled.

______________________________________

But here's the 'magic' part how to get .onion resolution across a Linux system:

get the following packages (Ubuntu, Debian)

    sudo apt-get install tor iptables dnsmasq dnsutils

    VirtualAddrNetworkIPv4 10.192.0.0/10
    AutomapHostsOnResolve 1
    TransPort 9040
    DNSPort 53
    DNSListenAddress 127.0.0.2

    sudo service tor restart

    listen-address=127.0.0.1
    resolv-file=/etc/realresolv.conf
    server=/onion/127.0.0.2

    nameserver 107.170.95.180 (or whatever nameserver you choose)
    nameserver 8.8.8.8

    sudo service dnsmasq restart

    sudo iptables -t nat -A OUTPUT -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040

    /sbin/iptables -t nat -A OUTPUT -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040

god of magic form: https://upload.wikimedia.org/wikipedia/en/thumb/2/2a/Angelke...

And was really, one of the best villains I've ever seen in any game/movie. Intentionally poisoning everyone, for expediency, is disgustingly evil.

I have my IoT system across multiple networks, some of which I do not control the router. One possible solution was to have my VPS machine provide tunnels in a star topology. It's pretty sucky for the star center, because they end up getting all the traffic. And it's also pretty hard.

Another solution was to dyndns, port forwarding, router redirection, poking through NATs and all that... for each location I'm in. That's bad. Real bad.

Perhaps I could do some point-to-point trickery... but that doesn't work when both machines are NATted.

Tor Hidden Services provides a way to automatically breach the network seamlessly, and provide a routable address to that machine, no matter where that machine is. I take it to a cafe in Washington DC? Within 10 seconds, it's back on Tor. South America? 10 seconds.

The topology, once done, looks like a humongous ethernet hub, with no promiscuity mode. And each node is the 16 char hash.

Then, I can code against .onion addresses. They just work, and I know if I establish a connection, I can send data.

I'm already sending MQTT telemetry data from one network to my broker in another house 30 miles away. And it's sending pictures and metadata both. And it just works.

EDIT response:

>What kind of throughput & latency do you usually see?

Latency is a bigger one, obviously. It depends on the construction of the bridge. If I'm not using any overlays (OBFS3, OBFS4, scramblesuit, etc) then initial lag times can go in excess of 30 seconds. Once that initial connection is established, then lag times go down to about 200-300ms range.

Using overlays, because the network blocks various vanilla types of Tor, can take a lot longer. That's because those overlays are beat on by China and Iran. Sometimes they will dead-route packets (5% of the time). Initial transit I've seen up to 1 minute, with avg ping times around 500 ms.

Throughput is a different beast. The only network I haven't saturated was my 1GBps desktop at work. I can stream movies directly with the speeds I routinely get. Just that initial bridge construction will make you think something went wrong.

(responded here because "I'm responding too fast")

I imagine this is a lot better than hitting an exit node.

http://security.stackexchange.com/questions/36930/how-does-w...

Websockets don't use standard HTTP requests other than using standard ports. The header lines not mentioned in RFC 2616 get removed by a lot of corporate firewalls (that includes filtering proxies etc.).

However, I've often seen port 443 being blocked :|.