unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Boaz Segev <boaz@2be.co.il>
To: Sam Saffron <sam.saffron@gmail.com>
Cc: Michael Fischer <mfischer@zendesk.com>, Eric Wong <e@80x24.org>,
	unicorn-public <unicorn-public@bogomips.org>
Subject: Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`
Date: Mon, 8 Aug 2016 23:17:53 -0400	[thread overview]
Message-ID: <A8E4D0F8-923F-4A2E-9113-2754133C5054@2be.co.il> (raw)
In-Reply-To: <CAAtdryPZX-9RoADT_UyYNkKUBN4f+gytUNpAOWS6UdT1obqGRw@mail.gmail.com>

Hi Sam,

I just wanted to point out that the specification was meant to be optional and this is why it includes the `env['upgrade.websocket?']` flag to indicate support. 

I don't think every server has to support Websockets - different server architectures favor different tasks and performance isn't a one size fit all.

However, it's high time (if not a bit late) Ruby had better support for applications that decide to use Websockets - which is, obviously, not all of them (I doubt that many applications need them).

I think it's wrong that Websockets are so complicated to implement in Ruby and Rack. The technology might be dangerous, but it does have it's uses (such as large file uploads, inter-app micro-services, game servers... to name just a few use-cases that survive HTTP/2).

- Bo.

> On Aug 8, 2016, at 21:08, Sam Saffron <sam.saffron@gmail.com> wrote:
> For the record Eric,
> We use unicorn at Discourse to serve concurrent long polls across 100s
> of hosted forums using hijack with zero issues using
> https://github.com/SamSaffron/message_bus
> I am not particularly enthused WebSockets and have blogged about my
> reservations, in an HTTP/2 world I am less clear about how they fit in
> except for some very niche uses.
> If this becomes a core Rack specification and now forces all Rack
> implementation to carry around websocket framing protocol and
> epoll/kqueue I would also be less excited.
> On Sat, Aug 6, 2016 at 5:37 PM, Boaz Segev <boaz@2be.co.il> wrote:
>>>> Michael said
>>> Unicorn is a forking webserver, not an event-driven or threaded
>>> webserver.  Whether Unicorn ever supports the proposed standard or
>>> not, I wouldn't recommend it be used for typical applications that use
>>> WebSockets, as they usually involve persistent connections.  Unicorn
>>> would quickly run out of worker processes capable of serving such
>>> connections anyway, so I question whether it's worth delving into the
>>> dirty details of IO syscalls.
>>>> Eric said
>>> Sorry, not interested, and definitely not touching centralized
>>> message boards :>
>> I totally understand and I thank you both for your time.
>> -- Bo.

  parent reply	other threads:[~2016-08-09  3:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-05 23:49 Please join the Rack Specification discussion for `env['upgrade.websocket']` Bo
2016-08-06  1:01 ` Eric Wong
2016-08-06  3:09   ` Boaz Segev
2016-08-06  4:10     ` Michael Fischer
2016-08-06  7:37       ` Boaz Segev
2016-08-09  1:08         ` Sam Saffron
2016-08-09  2:42           ` Eric Wong
2016-08-09  3:17           ` Boaz Segev [this message]
2016-08-06  4:59     ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A8E4D0F8-923F-4A2E-9113-2754133C5054@2be.co.il \
    --to=boaz@2be.co.il \
    --cc=e@80x24.org \
    --cc=mfischer@zendesk.com \
    --cc=sam.saffron@gmail.com \
    --cc=unicorn-public@bogomips.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).