[IPython-dev] Notebook websocket change

Kyle Kelley rgbkrk at gmail.com
Thu Jan 8 14:33:52 EST 2015


You're right Brian, it's about them buying some
$FIREWALL_IPS_SUPER_PRICEY_DEVICE that doesn't proxy websockets
appropriately and the person purchasing having no clue other than the fact
that $VENDOR gave them a neat trinket at a conference.

Firewalls and proxies that do handle websockets appropriately do exist. I'd
be tempted to make a list of ones that do it well and display them
prominently, if only for the benefit of our own users.

I have witnessed these flavors of IPython in the wild (not including our
own recent stunts):

* Corporate entities using an Anaconda server (websockets not a problem
internally but were externally)
* People of all backgrounds using Anaconda's IPython notebook bundling
* Vanilla installations from package managers or pip
* Hosted instance of their own flavor
* DIT4C

Most users that we hear from are using a local installation and there's
probably a large amount of confirmation bias. It would be great if we had
actual shared metrics between us but we only know:

* Unique viewers/users of the Nature demo (> 14,000 total, according to GA)
* Viewers on the notebook viewer (> 200k per month, also according to GA)
* Downloads on PyPI (skewed, not unique)
* Clones from github (also skewed)

We could actually be tracking who has websocket support of those hitting
the notebook viewer for a bigger sense of potential users (since viewers
are not necessarily IPython/Jupyter users).



On Thu, Jan 8, 2015 at 12:55 PM, William Stein <wstein at gmail.com> wrote:

> On Thu, Jan 8, 2015 at 10:19 AM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > So far we have felt that it isn't worth the complexity cost for us to
> > support people that deliberately choose to break the internet. It is not
> > like WebSockets is some crazy, insecure, unsupported hack over a weird
> port.
> > It is just different bytes going over the same HTTP/HTTPS socket
> connection
> > and is essentially a formal standard (I know you know this - this is our
> > messaging to companies who complain).
>
> I know -- that's why I switched SMC to pure websockets for a while.
> Then I received complaints at a rate of about 2 very desperate users
> per week, and these were the people who cared enough to complain
> repeatedly.
>
> > Our situation is a bit different though than SMC because most of our
> current
> > users run the notebook on their own computers. This may be something
> that we
> > eventually want to rethink as more people run this in the cloud.
> However, I
> > would like to push back on the companies choosing to break the internet
> > really hard before giving in. I am guessing that in most cases,
> WebSockets
> > are broken in enterprise setting not because of some important deliberate
> > choice, but rather because people don't understand it and are using
> default
> > settings that disable them (I could be wrong though)....
>
> In my experience, for some people that's exactly the problem.  For one
> person I helped it turned out their specific problem was the Windows
> install they had access to had websockets explicitly disabled --
> perhaps that was an IT policy.  For other people the problem is
> further along the stack (e.g., possibly involving caching).
>
> Anyway, this change so that "there is a single websocket connection
> between the server and client. " makes implementing an alternative to
> WebSocket as a fallback dramatically easier, which I greatly
> appreciate.
>
> > Our situation is a bit different though than SMC because most of our
> current
> > users run the notebook on their own computers. This may be something
> that we
>
> Just curious -- how do you know that most people using IPython aren't
> already using it through SMC?
>
> William
>
> >
> > Cheers,
> >
> > Brian
> >
> >
> >
> > On Thu, Jan 8, 2015 at 10:10 AM, William Stein <wstein at gmail.com> wrote:
> >>
> >> On Thu, Jan 8, 2015 at 10:04 AM, MinRK <benjaminrk at gmail.com> wrote:
> >> > Alternative notebook frontend authors:
> >> >
> >> > There is an upcoming change to websocket connections to the notebook
> >> > server.
> >> > Instead of three websockets per notebook, one for each zmq channel,
> >> > there is
> >> > a single websocket connection between the server and client. The
> channel
> >> > associated with each message is identified by a channel key in the
> >> > message
> >> > dict itself.
> >> >
> >> > Relevant changes:
> >> >
> >> > url is /channels instead of /shell, etc.
> >> > when sending a message, add a channel key with the channel name
> >> > ('shell',
> >> > 'stdin')
> >> > when receiving a message, check the channel key for routing
> >> >
> >> > -MinRK
> >>
> >> Thanks.
> >>
> >> Of related interest, what the situation involving providing a fallback
> >> to websockets?
> >>
> >> I tried to only support websockets connections with SageMathCloud for
> >> a few weeks, and immediately ran into many complaints from users who
> >> couldn't connect as a result.   This is even with https and so on --
> >> it's just a sad fact that in some corporate or otherwise constrained
> >> environments that websockets don't work.   By far the best approach I
> >> found was to use Primus + Engine.io, which uses websockets if
> >> possible, but will fallback to polling.   So this is what SMC does
> >> now, and everything works, even for people that don't have websockets
> >> as an option... except for IPython-in-SMC of course, which doesn't
> >> work.
> >>
> >> Another unrelated issue is that I'm now hardcoding making this change
> >> around line 171 of IPython/html/notebookapp.py, since I want to serve
> >> the purely static html of IPython from a completely different web
> >> server:
> >>
> >>             #static_url_prefix = url_path_join(base_url,'/static/'),
> >>             static_url_prefix = '/static/ipython/',
> >>
> >> (Sorry for derailing the thread.)
> >>
> >>  -- William
> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > IPython-dev mailing list
> >> > IPython-dev at scipy.org
> >> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >
> >>
> >>
> >>
> >> --
> >> William Stein
> >> Professor of Mathematics
> >> University of Washington
> >> http://wstein.org
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> >
> > --
> > Brian E. Granger
> > Cal Poly State University, San Luis Obispo
> > @ellisonbg on Twitter and GitHub
> > bgranger at calpoly.edu and ellisonbg at gmail.com
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Kyle Kelley (@rgbkrk <https://twitter.com/rgbkrk>; http://lambdaops.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150108/4320a011/attachment.html>


More information about the IPython-dev mailing list