From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 74BA820558 for ; Sat, 6 Aug 2016 03:09:48 +0000 (UTC) Received: by mail-qk0-f174.google.com with SMTP id t7so3653487qkh.0 for ; Fri, 05 Aug 2016 20:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2be-co-il.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+WjW6/XCXy94cDo3nUIt5NHr2MtxEmO9BNrY/lJlq6o=; b=XRHbohjPbgp2pIMMCzEI38Dz0xBbWCl+NAOzXD0haaP51vL/V/u8baDV/fvH2nBW2y 4eqgtoCjnCnc1Mh7NgHG+d1wjYXB6f9E1Hj/fwOkw0H32EKy/gGPItifMVxnicpX0i2W lrnXwwkEAH0dgsUdOeRKqBMXkbzZ6QeMybN0P/bvuFr5en7vW6PQWDIetoD6uXNahd3Q OLXzmcF/O6UN+FzaKqw1HL3sqcYaklfjsRIkt5FpVd8HnNd49zQxingqOy9O+yhpmF+a xn5Bshq+dgOKs4fwaZOYEuvvwOmZdX9JYp9Vk5wKJMHbZ2fikJfbpuSWm47LQSYHA4tq 6Fbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+WjW6/XCXy94cDo3nUIt5NHr2MtxEmO9BNrY/lJlq6o=; b=dQYuml+5ncD1Ze2529ZsSCRafjtsUdATx8No1QhsrpeIqCtm+5w5ElR055/P57H1mh XT5+ESNrFx1/W79bS4f6rotSBQ1GA8m8WJthG3AQKlhnjclDlnckpbCCnwsYnV2IYZTn 6zaRnTR9Xj7aI9YbqZPJm0UcBNUN4HFqNme3FrvTTrPJJif7eVxQEMyBeE/mRY9d3s0q hSNmL56jVIfw2g630qCVBLxHJjGlkVHWmR1spaQbqFUOO6r0UdFFQ0OClY5jY3vlUBQz iHCjO8Gu8OIhftJHYPOQNvEIB22Ge15MTXUUifXrg9R9wl5CsDmit3K09/hAEzhxBAOw vpKA== X-Gm-Message-State: AEkooutC9IJdk/0YWEohbZ26cWQp55fjUgKsYo/VSbJsVx3lFbORZLghfAEnhfQR8thRQQ== X-Received: by 10.233.237.75 with SMTP id c72mr15961636qkg.170.1470452987364; Fri, 05 Aug 2016 20:09:47 -0700 (PDT) Received: from ?IPv6:2601:197:200:3353:908e:7415:ca7:a253? ([2601:197:200:3353:908e:7415:ca7:a253]) by smtp.gmail.com with ESMTPSA id n143sm11312632qkn.27.2016.08.05.20.09.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 05 Aug 2016 20:09:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Please join the Rack Specification discussion for `env['upgrade.websocket']` From: Boaz Segev In-Reply-To: <20160806010126.GA7486@dcvr> Date: Fri, 5 Aug 2016 23:09:45 -0400 Cc: unicorn-public@bogomips.org Content-Transfer-Encoding: quoted-printable Message-Id: <202FC1D8-3042-4CBF-9DEA-85D1BEA080F3@2be.co.il> References: <58D32D89-4523-436E-8C0E-FA8F4E7AFFB2@plezi.io> <20160806010126.GA7486@dcvr> To: Eric Wong X-Mailer: Apple Mail (2.3124) List-Id: Eric, thank you for your review and thoughts on the matter. You raised a few questions, please allow me to both answer and clarify = the intention behind the proposed extension. >> I represent an effort to extend Rack so that it allows server-side >> websocket upgrade implementation support and pure Rack websocket >> applications. >>=20 >> This new Rack feature proposal is gaining support, with over 42 >> support votes in the [original Rack discussion >> thread](https://github.com/rack/rack/issues/1093). >=20 > You mention performance several times, but I am not sure what > you mean. unicorn completely stops caring for a socket after > it's hijacked by the app. In other words: >=20 > Your Rack app could take the socket and inject it into an > event loop running in a separate thread. That event loop > could be 100% C code running without GVL for all unicorn > cares. Running two (or more) event loops, each with it's own resources, is = wasteful and promotes needless context switches. There is no reason to hijack a socket when the server can easily provide = callbacks for IO related events using it's existing established event = loop. This alone should provide a performance boost. There are other = considerations as well, but I think they all derive from this core = principle of having the web server retain control over all network IO = concerns. > Also, Ruby IO.select also supports arbitrary number of > descriptors in some cases (Linux for sure, and probably most > server-oriented *BSDs). Of course, the malloc usage + O(n) > behavior still suck, but no, select(2) is not always limited to > <=3D1024 FDs. Although this isn't as relevant to the proposed specification, it is a = good example for how intricate network programming details are unknown = by most Ruby programmers and shows why it would be better for the web = server to retain control over all network IO concerns. For example, the Linux man page expressly states that "To monitor file = descriptors greater than 1023, use poll(2) instead" This is true even when using select for a single FD that has a value of = more then 1023, since `select` is often implemented using a bit vector = map of 1024 bits that are controlled using the FD_(*) macros. See, for example: = http://linux-tips.org/t/is-it-possible-to-listen-file-descriptor-greater-t= han-1024-with-select/45/2 Ruby's IO.select uses this same system call and suffers the same issues = that are present in the OS - each OS with it's own quirks. I don't think application developers should worry about these details = when these issues were already resolved during the server's designed. By having the server provide callbacks - instead of hijacking - we = eliminate a hoard of potential bugs and considerations. > unicorn would only parse the first HTTP request (with the > Upgrade header) before the Rack app hijacks it. Of course, not every server has to offer this feature - just like = hijacking, it's optional. Unicorn was design for very specific use cases, so I definitely = understand if this might not be as interesting for you.=20 However, I do think your experience as developers could help enrich us = all. If you have any comments or anything to add regarding the proposed = `websocket.upgrade` specification, your voice is welcome: https://github.com/boazsegev/iodine/issues/6