New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Websockets with web interface #952

Closed
dariusc93 opened this Issue Jan 8, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@dariusc93
Contributor

dariusc93 commented Jan 8, 2015

Is there a more manageable way to setup websockets within a web interface?

@dariusc93 dariusc93 closed this Feb 27, 2015

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Feb 27, 2015

Member

Hm, I thought that a convenient way had already been implemented at some point (with making a web interface method like void getWS(WebSocket socket) { ... }). But the code is obviously not there. You can consider this as a planned feature, though.

BTW, if you have anything where I didn't reply yet, feel free to ping me. I didn't get to read my GitHub notifications and forum messages from roughly October to early February,

Member

s-ludwig commented Feb 27, 2015

Hm, I thought that a convenient way had already been implemented at some point (with making a web interface method like void getWS(WebSocket socket) { ... }). But the code is obviously not there. You can consider this as a planned feature, though.

BTW, if you have anything where I didn't reply yet, feel free to ping me. I didn't get to read my GitHub notifications and forum messages from roughly October to early February,

@dariusc93

This comment has been minimized.

Show comment
Hide comment
@dariusc93

dariusc93 Feb 27, 2015

Contributor

Thank you for your reply. I try to avoid pinging unless i feel I need too (when urgent that is)

Contributor

dariusc93 commented Feb 27, 2015

Thank you for your reply. I try to avoid pinging unless i feel I need too (when urgent that is)

@dariusc93 dariusc93 reopened this Feb 27, 2015

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Feb 27, 2015

Contributor

I think this would quickly become deprecated, with HTTP/2 around the corner we're about to revive "long polling", because connections are now simply different "streams" living inside a single TCP Connection. The "long poll" would be a sleeping vibe.d Task in this case, with the same protocol overhead no matter how many of them are present. You can have a TaskPool of 5 long polling HTTPServerRequests and it remains very lightweight, so you can keep serving your pages using (HTTPServerRequest req, HTTPServerResponse res).

Also, although HTTP/2 is a one-way protocol (client->server or server->client), I'm adding a feature that allows to switch the direction (for RPC), giving a server the ability to become the client, and a client to become a server even though it's behind NAT & firewalls. The client can then start another HTTP2Connection and have both, a client and server HTTP2Connection with support for unlimited concurrent streams (HTTPClientRequest, HTTPServerRequest) under a single TCPConnection, using the regular vibe.d request handling syntax.

Contributor

etcimon commented Feb 27, 2015

I think this would quickly become deprecated, with HTTP/2 around the corner we're about to revive "long polling", because connections are now simply different "streams" living inside a single TCP Connection. The "long poll" would be a sleeping vibe.d Task in this case, with the same protocol overhead no matter how many of them are present. You can have a TaskPool of 5 long polling HTTPServerRequests and it remains very lightweight, so you can keep serving your pages using (HTTPServerRequest req, HTTPServerResponse res).

Also, although HTTP/2 is a one-way protocol (client->server or server->client), I'm adding a feature that allows to switch the direction (for RPC), giving a server the ability to become the client, and a client to become a server even though it's behind NAT & firewalls. The client can then start another HTTP2Connection and have both, a client and server HTTP2Connection with support for unlimited concurrent streams (HTTPClientRequest, HTTPServerRequest) under a single TCPConnection, using the regular vibe.d request handling syntax.

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Jul 26, 2015

Member

Implemented by 41bdae6.

@etcimon: True about the HTTP/2 streams, but the world will change slow enough that people will surely still want to use this for a while. It has also been a really simple implementation, so why not.

Member

s-ludwig commented Jul 26, 2015

Implemented by 41bdae6.

@etcimon: True about the HTTP/2 streams, but the world will change slow enough that people will surely still want to use this for a while. It has also been a really simple implementation, so why not.

@s-ludwig s-ludwig closed this Jul 26, 2015

@etcimon

This comment has been minimized.

Show comment
Hide comment
@etcimon

etcimon Jul 26, 2015

Contributor

Yeah HTTP/2 is being adopted very slowly according to recent statistics. But wow, I totally forgot I had had this idea. I was imagining a client stream that can interchange its role with a server (to become another HTTP/2 server over a single HTTP/2 stream, but behind a firewall). I ended up concluding that polling on multiple streams simultaneously would do just fine to avoid latency, but I'm sure someone will end up implementing it eventually.

Contributor

etcimon commented Jul 26, 2015

Yeah HTTP/2 is being adopted very slowly according to recent statistics. But wow, I totally forgot I had had this idea. I was imagining a client stream that can interchange its role with a server (to become another HTTP/2 server over a single HTTP/2 stream, but behind a firewall). I ended up concluding that polling on multiple streams simultaneously would do just fine to avoid latency, but I'm sure someone will end up implementing it eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment