With ipv6 they can now be fully scaled easily but they are absolutely awesome, much easier to scale because you can give your client a simple list of sse services and its essentially stateless if done right.
Websockets get really complex to scale past a certain level of use.
In theory direct connections between all devices on the internet. In practice, everything's still going to be behind a firewall. But it's still an improvement over NAT, and hopefully we'll eventually get universally adopted protocols for applications to open ports.
I've been using IPv6 more recently, and one nice thing as a developer is being able to use the same IP address for local connections and internet connections. Simplifies managing TLS certs for example, since the IP address used by Let's Encrypt is the same one I'm connecting to while developing.
You misunderstand. I'm asking why IPv6 would help this specific situation, not why ipv6 is nice in general. None of what you said applies to this context.
You're right, I was responding to your comment directly and not taking context into account.
I guess maybe what GP is getting at is that with vhosts on IPv4 you need to have some sort of load balancer in order to share the IP, but with IPv6 you can flatten this out and give every host it's own IP?
If you have multiple machines with their own IPs, v4 or v6 makes no difference. If you have a single machine (vhosting), the number of IPs and their type makes no difference.
I will quote the comment you are trying to justify:
> With ipv6 they can now be fully scaled easily but they are absolutely awesome, much easier to scale because you can give your client a simple list of sse services and its essentially stateless if done right.
If you don't understand it either please stop saying random stuff about IPv6 that we already know and has nothing to do with this thread.
How is it limited? How is it less limited with IPv6?
A client gets an SSE endpoint (hostname). That endpoint maps to an IP. A server at that IP receives the connection. Which part is better with v6?
Are we talking about the few cents it would cost you to give each server an IPv4? Are we thinking about a distant future where that cost is not negligible compared to the cost of compute? Something else?
So that was the only argument. Wow, I'm glad I finally got to it, but I'm not amazed. All it took is making it up myself.
I don't use AWS so ok thanks. And if I did, I would use their ingress/gateway solutions, which totally circumvent this problem (while being quite expensive anyway).
I agree, AWS is way too expensive. In fact you have a good point which is that the cost of compute on AWS is significantly higher, such that the relative cost of IPs isn't as significant. You can get a solid VPS from Hetzner for the cost of an AWS IP address.
I don't feel it would be right to just give you an answer after chasing yours 11 messages deep and finally having to make it up myself. I don't have the kind of emotional energy it takes to communicate with you.
Similitudes in timbre. There is plenty of room for improving the state of the web. Not 100% certain IPV6 is that, but it certainly offers more address space, and that would be foolish to avoid embracing simply because old tech is duct-tape-able enough.
is anybody actually able to disable ipv4? maybe if you only serve vpn or internal users?
This might be the best thing about Elixir/Phoenix LiveView. I haven't actually had to care in quite some time :-) (though to be fair, I keep things over the websocket pretty light)
Yeah there's 6to4 schemes. It's common in the U.S. for cell providers to give IPv6 but private IPv4 and do NAT (although IPv4 could be skipped altogether)
AWS you can use NAT Gateways for 6to4 and do v6 only subnets
> SSE connections keep a mobile device’s radio powered up all the time. You should avoid connecting a SSE stream on a device that has a low battery, or possibly avoid using SSE at all unless the device is plugged in.
I don't think keeping sockets open waiting for incoming data have big impact on battery usage because there is no data transmission at that moment so radio shouldn't consume much energy in stand-by mode.
I use K9-Mail app for email working 24h a day, it has multiple accounts on different IMAP4 servers. You know, IMAP requires one keep-alive socket per subscribed folder and I have no problem with battery usage.
I don’t think IMAP is a good example here. Your email client will try both subscribing and classic polling. Subscribing is not a MUST. And from the point of view of end user, the difference when polling in a classical way is simply that the user will be notified later, so it’s hard to tell what the client really did in the background.
I agree. Unfortunately you can only have 6 SSE streams per origin per browser instance, so you may be limited to 6 tabs without adding extra complexity on the client side.
edit: From the article:
To workaround the limitation you have to use HTTP/2 or HTTP/3 with which the browser will only open a single connection per domain and then use multiplexing to run all data through a single connection.
No, if you can enable TLS and HTTP/2|3, you are only technically using a single browser connection, onto which multiple logical connections can be multiplexed.
I think the article calls this out. There is still a limit on the number of logical connections, but it's an order of magnitude larger.
A service worker would work fine; the connection would be instantiated from the SW and each window/worker could communicate with it via navigator.serviceWorker.
Edit: of course you could use: https://caniuse.com/sharedworkers but android does not support it. We migrated to the lib because safari took its time… so mobile was/is not a thing for us
Yes, but the limit is different (usually much higher) and negotiated, up to maximum SETTINGS_MAX_CONCURRENT_STREAMS (which is fixed at 100 in Chrome, and apparently less in IOS/Safari.)
SSE are really a subset of Comet-Stream (eternal HTTP response with Transfer-Encoding: chunked) only they use a header (Accept: text/event-stream) and wraps the chunks with "data:" and "\n\n".
But yes it's the superior (simplest, most robust, most performant and scalable) way to do real-time for eternity.
The browser is dead, but SSE will keep on doing work for native apps.
