

CloudFlare Now Supports WebSockets - jgrahamc
http://blog.cloudflare.com/cloudflare-now-supports-websockets

======
drinchev
I'm a super big fan of CloudFlare and I especially appreciate when a CEO / Co-
founder of a successful company stays so close to it's customers by writing a
detailed blog post about features/problems they achieved/solved.

~~~
eastdakota
Thanks, that's kind of you to say. One of my favorite parts of my job is I am
surrounded by really smart engineers who I constantly learn new things from.
In this case, Marek spent a bunch of time with me walking through the innards
of how Linux sets up a socket. Was a lot of fun to learn about and write up.
If you want an even more technical post on the subject, you should check out
his blog:

[https://idea.popcount.org/2014-04-03-bind-before-
connect/](https://idea.popcount.org/2014-04-03-bind-before-connect/)

~~~
dmunoz
You mean he didn't just tell you to go read Beej's guide [0]?

Joking aside, I really enjoy reading Cloudflare's blog posts. I know they
don't just pop into existence without some serious effort. Thanks for taking
them seriously.

[0] [http://beej.us/guide/bgnet/](http://beej.us/guide/bgnet/)

------
zrail
Something seems off on the second code example under "Safely Reusing Ports".
`s.connect()` is inside the try/except block, which is great, except that both
cases in the `except` re-raise something, which means the loop will only ever
execute once. Am I misreading that?

Not that that takes anything away from the functionality, of course.
CloudFlare is great and I'm excited to see that they're offering web socket
support.

~~~
jgrahamc
Thanks for pointing that out. It's a problem with the indentation of the
pseudo-Python code in our blog editor. I've fixed it.

~~~
zrail
Thanks! Now it makes much more sense.

------
bsaul
Isnt't websocket used mainly for event based communication to clients ? That
would seem like something absolutely impossible to cache or proxy, not because
of the technology itself but because the content seems almost specific every
time. What would the be the business case for using cloudflare with websockets
?

~~~
andrewstuart2
There could be a huge benefit for someone who wants to send websocket frames
to say, 100,000 clients. You can't do that with a single server; you'd run out
of ports (reuse aside). You'd also have a lot of load on one server. At the
cost of a little latency to the true event, you can increase performance and
scalability dramatically by sending the event to just a few intermediaries
that then broadcast the event to a subset of clients.

~~~
toast0
> There could be a huge benefit for someone who wants to send websocket frames
> to say, 100,000 clients. You can't do that with a single server; you'd run
> out of ports (reuse aside).

You would not run out of ports, as long as your clients have some IP
diversity. Connections must be unique with the key being the 5-tuple:
{Protocol, SourceAddr, SourcePort, DestAddr, DestPort}. If you have one server
listening on one port, each client address can theoretically have 65535
connections (in practice, you're unlikely to find a client that will allocate
their ports well enough to use all the ports).

Assuming your websockets are mostly idle, handling 100k connections for one
server doesn't really need that big of a server either, see WhatsApp blog post
about 2.2 million connections on one server in 2012:
[http://blog.whatsapp.com/196/1-million-is-
so-2011](http://blog.whatsapp.com/196/1-million-is-so-2011) Caveats: dual
6-core westmere cpu, 100 G ram, normal connection count is lower per server;
connections are mostly idle; some tuning required. See also 2.8 M connections
documented on page 16 of Erlang Factory presentation: [http://www.erlang-
factory.com/upload/presentations/558/efsf2...](http://www.erlang-
factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf)

------
dpweb
Like Cloudflare alot. I've dropped web sockets in favor of SSE personally, but
I've been very happy with their caching so far even on the free plan.

------
mnarayan01
If my vague memory is correct, using SO_REUSEADDR can (at least theoretically)
cause (undetectable) TCP issues. If a connection on a particular (source
address, source port, destination address, destination port) tuple is closed
locally and then another connection is opened on the same tuple _before_ the
TTL time has passed, the new connection may receive (sans error) data which
was intended for the old connection (again, IIRC).

~~~
nly
Wouldn't the sequence numbering differ?

~~~
mnarayan01
Yea at least given modern ISN generation mechanisms I would think it would.
Back when I was looking at it, the typical means of ISN generation may have
been more naive?

I'm also hazy on the exact fail case...it may also have had something to do
with a FIN message getting lost, though I would think that would also be
handled by the sequence number.

------
kordless
I skimmed the article looking for information regarding IPv6 support. Is it
possible for a client to establish an IPv4 socket to CloudFlare and then
CloudFlare talk to my server over IPv6?

~~~
jgrahamc
Yes, we support that.

~~~
kordless
That's awesome. Thank you!

I'm thinking of using something like this: [https://github.com/sstur/node-
websocket-tunnel](https://github.com/sstur/node-websocket-tunnel) to allow
access to StackMonkey instances by way of an IPv4 route if the customer
doesn't have IPv6 enabled on their network.

