Skip to content
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

[FEATURE]Use WebSocket #244

Open
zyxgad opened this issue Sep 11, 2021 · 8 comments
Open

[FEATURE]Use WebSocket #244

zyxgad opened this issue Sep 11, 2021 · 8 comments

Comments

@zyxgad
Copy link

zyxgad commented Sep 11, 2021

I suggest bluemap use WebSocket to get data, that will reduce many unnecessary web request. Of course, bluemap need keep http API to compatible with the old client

@roobscoob
Copy link

If this is to be implemented, please keep the HTTP fetch option as a persistent choice. (i.e. don't deprecate/remove it). When deploying BlueMap at scale (for example, as an interactive component displaying a static world on a website) HTTP fetches are much better, as tools exist to optimize the delivery of static content over HTTP. These same tools do not exist for WebSockets

@FinlayDaG33k
Copy link

Do note that if websockets are going to be used, we'd also need to implement RFC 7692 in order to use some compression.

@TBlueF
Copy link
Member

TBlueF commented Nov 14, 2021

There is currently no intend to use web-sockets for the map-tiles .. in my opinion, http-requests are perfectly fine for that :)
The web-sockets would be for live-updates like player-markers

@mrsolarius
Copy link
Contributor

Maybe instead of web socket, just use server side event ?

@TBlueF
Copy link
Member

TBlueF commented Jul 3, 2024

I will consider it, yes :)

@FinlayDaG33k
Copy link

FinlayDaG33k commented Jul 3, 2024

With HTTP/3 becoming more common by the day, I'd say websockets wouldn't add much anymore.
The only thing I'd see websockets being useful for, is making things like player-locations be available in a more real-time fashion as mentioned in #244 (comment).

Pros

  • HTTP/3 is built on QUIC/UDP, which eliminates head-of-line blocking and ack packets (server assumes arrival, client will request packets when they go missing).
  • No need to do anything in the client front-end (the browser will handle it).
  • It's still just HTTP, so compression and all those goodies will remain in-tact (so no need to do wonky stuff like I've mentioned in [FEATURE]Use WebSocket #244 (comment)).
  • Clients that do not support HTTP/3 can still use HTTP/2 or even HTTP/1.1 as normal.
  • Doesn't break setups that use a CDN (or something similar).

Cons

  • TLS is a must (might be the biggest part of the challenge).
  • HTTP/3 is technically still just a proposal (albeit it has pretty much stabilized).

I do not know how the internal webserver works from a code-perspective but I think the changes should be relatively minimal while still having a bigger impact than using websockets would have.

@Chicken
Copy link
Member

Chicken commented Jul 3, 2024

HTTP/3 is unlikely to be ever supported by BlueMap as it has been previously established that BlueMap won't support TLS by itself. To use HTTP/3 one should host the website with an external webserver such as nginx.

@brianclogan
Copy link

I would say using websockets for external live updates would be amazing. Maybe if hosted by the server it still does HTTP requests, but if you move external you have the option of using websockets instead of ajax requests for player positions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Planned (unordered)
Development

No branches or pull requests

7 participants