[dev-servo] Upgrading HTTP requests to WebSocket with rust-websockets.

[Eddy Bruel]

I am currently writing a prototype of a debugger server for Servo that
works with the Chrome Debugging Protocol:
https://github.com/ejpbruel/servo/tree/acceptor

The Chrome Debugging Protocol works by first sending a HTTP request to
http://localhost:/json (where  is the remote debugging
port). This returns a JSON array of objects, each of which describes a
debugging target. Among other things, this description includes a WebSocket
URL for the target.

Both the HTTP URL for the initial request and the WebSocket URLs for the
individual targets, use the same remote debugging port. This is a problem,
since the rust-websocket library that we use in Servo currently does not
support handling HTTP requests over the same port as the WebSocket server.

I did find the following pull request
 that seems to
implement the functionality we need, but for some reason it never landed
(the last comment is over a month old).

The way I see it, we have two options. Personally, I'm leaning towards
option two, but I wanted to get your opinion:

1. Ignore the problem for now. Most debugger clients for the Chrome
Debugging Protocol can attach to a WebSocket URL directly; since Servo only
supports a single tab right now anyway, we don't really need that initial
HTTP request.

2. Poke the author of the rust-websocket library and see if we can get that
pull request landed.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] How to shut down a WebSocket server

[Eddy Bruel]

As I mentioned in my previous post, I am trying to use the rust-websocket
library to implement a prototype debugger server for Servo.

The main server thread needs to wait for one of the following events:
1. An incoming WebSocket connection.
2. A message from the browser

Unfortunately, the former uses a TCP socket, and the latter a mpsc
receiver, and it is not possible to select on both.

To avoid this, we listen for incoming WebSocket connections on a separate
acceptor thread, and then send the connection in a message over the mpsc
channel. This way, the main server thread can wait for both types of event.
Note that this is exactly what we do in the existing devtools server.

One message that the browser should send to the server is a request to
shutdown the server. When the server receives a shutdown request, it should
close all open connections, and then shut down the server.

Unfortunately, as far as I can tell, the rust-websocket library does not
provide a way to shut down a server. This means we have no way to break the
acceptor thread out of its loop; we can't send it a notification, since it
is blocked waiting on an incoming connection. The result is that we end up
leaking the acceptor thread on shutdown.

I can see the following options here. I am leaning towards option 2, but
option 3 is also something we could consider. What are your opinions?

1. Ignore the problem. This is what we do in the existing devtools server.
After all, what is a leaked thread among friends?

2. Write a pull request to add this functionality to rust-websocket. Since
the library uses TCP sockets under the hood, this should be as simple as
closing the listener socket (is it possible to do this from another
thread?). Doing so should break the acceptor thread out of its loop.

3. I found another websocket library for Rust, called "ws". Unlike
rust-websocket, ws seems to have a proper shutdown story (one can call a
shutdown() method on a Sender, which can be cloned between threads). It
also seems to be a bit more robustly designed than rust-websocket, so it
might be worth considering.

On the other hand, like rust-websocket, ws also does not provide a way to
upgrade HTTP requests to WebSocket. And unlike rust-websocket, there
doesn't seem to be a pending pull request to add this functionality, which
means we might have to implement it ourselves.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Upgrading HTTP requests to WebSocket with rust-websockets.

[Dirkjan Ochtman]

On Mon, Sep 12, 2016 at 1:14 PM, Eddy Bruel  wrote:
> The way I see it, we have two options. Personally, I'm leaning towards
> option two, but I wanted to get your opinion:
>
> 1. Ignore the problem for now. Most debugger clients for the Chrome
> Debugging Protocol can attach to a WebSocket URL directly; since Servo only
> supports a single tab right now anyway, we don't really need that initial
> HTTP request.
>
> 2. Poke the author of the rust-websocket library and see if we can get that
> pull request landed.

I was quickly looking at the pull request and was surprised to see
that no one had pinged the maintainer so far (since Jul 20). Since
that seems like a no-brainer that's useful for the ecosystem anyway, I
went ahead and pinged him. I'm not sure why you had not done so?

Cheers,

Dirkjan
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] How to shut down a WebSocket server

[Dirkjan Ochtman]

On Mon, Sep 12, 2016 at 1:45 PM, Eddy Bruel  wrote:
> 3. I found another websocket library for Rust, called "ws". Unlike
> rust-websocket, ws seems to have a proper shutdown story (one can call a
> shutdown() method on a Sender, which can be cloned between threads). It
> also seems to be a bit more robustly designed than rust-websocket, so it
> might be worth considering.

This may be a silly question, but why doesn't hyper come with
WebSockets support out of the box? It seems like "part of" HTTP to
some extent.

Cheers,

Dirkjan
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo testing as part of PhD dissertation

[Jack Moffitt]

> In addition to feeling less novel, QuickChecking JS
> APIs doesn't feel quite as useful for Servo testing (based on the
> assumption that Servo will be re-using *Monkey).

Most of the JS APIs are part of the DOM and not the built in objects.
These are implemented in the browser itself, not in SpiderMonkey, so
they have been totally rewritten in Servo.

I think your intuition that this is less novel is correct though.

jack.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

[dev-servo] Welcoming Josh Matthews to the Servo core team

[Lars Bergstrom]

We are delighted to announce that Josh Matthews is joining the Servo
core team (https://github.com/servo/servo/wiki/Governance).

Josh (jdm on IRC and GitHub) has driven planning for the DOM for
several years, coordinates most of our community programs, and is
already a contributor to other major decisions affecting Servo. As we
continue to push both to ship more components of Servo in Firefox and
define a standalone Servo product, we look forward to leaning on him
to help us grow the Servo community and push forward the web platform.

Please welcome Josh to the core team!
- Lars, Jack, and Patrick
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Welcoming Josh Matthews to the Servo core team

[Shing Lyu]

It's weird to say welcome, because it's jdm who introduced me to my first
few servo bugs. But welcome anyway!!

Shing

2016年9月12日 18:09，"Lars Bergstrom" 寫道：

> We are delighted to announce that Josh Matthews is joining the Servo
> core team (https://github.com/servo/servo/wiki/Governance).
>
> Josh (jdm on IRC and GitHub) has driven planning for the DOM for
> several years, coordinates most of our community programs, and is
> already a contributor to other major decisions affecting Servo. As we
> continue to push both to ship more components of Servo in Firefox and
> define a standalone Servo product, we look forward to leaning on him
> to help us grow the Servo community and push forward the web platform.
>
> Please welcome Josh to the core team!
> - Lars, Jack, and Patrick
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] How to shut down a WebSocket server

[Sean McArthur]

>
> This may be a silly question, but why doesn't hyper come with
> WebSockets support out of the box? It seems like "part of" HTTP to
> some extent.
>

Sorry this is offtopic from the subject, but just wanted to address the
question:

You won't find websockets in hyper for the same reason you won't find it in
any other HTTP library: it's not part of HTTP. It's a separate spec, only
relevant to web browsers.

It is always a goal though that hyper allows one to "upgrade" from HTTP/1.1
to any other protocol, mostly by just giving up access to the underlying
socket.
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] How to shut down a WebSocket server

[Michael Howell]

You could always have some random-generated-at-startup "shutdown token"
that you send through the WebSocket server itself, triggering it to break
out of the loop.

On Mon, Sep 12, 2016 at 10:33 AM Sean McArthur 
wrote:

> >
> > This may be a silly question, but why doesn't hyper come with
> > WebSockets support out of the box? It seems like "part of" HTTP to
> > some extent.
> >
>
> Sorry this is offtopic from the subject, but just wanted to address the
> question:
>
> You won't find websockets in hyper for the same reason you won't find it in
> any other HTTP library: it's not part of HTTP. It's a separate spec, only
> relevant to web browsers.
>
> It is always a goal though that hyper allows one to "upgrade" from HTTP/1.1
> to any other protocol, mostly by just giving up access to the underlying
> socket.
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo