Steam telepítése
belépés
|
nyelv
简体中文 (egyszerűsített kínai)
繁體中文 (hagyományos kínai)
日本語 (japán)
한국어 (koreai)
ไทย (thai)
Български (bolgár)
Čeština (cseh)
Dansk (dán)
Deutsch (német)
English (angol)
Español - España (spanyolországi spanyol)
Español - Latinoamérica (latin-amerikai spanyol)
Ελληνικά (görög)
Français (francia)
Italiano (olasz)
Bahasa Indonesia (indonéz)
Nederlands (holland)
Norsk (norvég)
Polski (lengyel)
Português (portugáliai portugál)
Português - Brasil (brazíliai portugál)
Română (román)
Русский (orosz)
Suomi (finn)
Svenska (svéd)
Türkçe (török)
Tiếng Việt (vietnámi)
Українська (ukrán)
Fordítási probléma jelentése
Ez a téma zárolásra került 
Hozzászólási szabályok és irányelvek
Hozzászólás jelentése
Steam already supports IPv6.
How exactly is the change of the address format going to help the connectivity? The physical networks are the same, the interpretation of the addresses is the same, the way packages are built is the same. Infact I would say packing an IPv6 package takes longer cause it's a more complex address format to be put into the header but overall the connectivity in general should be about equal or at least not noticeably different (from a gamers perspective)
The very reason why people introduced IPv6 is due to the immense need of addresses due to machines of all kinds becoming more and more relevant to the consumers department unlike a few decades ago where only very wealthy companies were in the position to afford any sort of internet-capable machines; nothing else.
One where the router does not some NAT64/NAT46 when going towards the internet.
Seriously, got a brand new modem direct preconfigured from my ISP recently, and it had ipv6 disabled by default. It's literally a checkbox and you join the 21st century! Why don't they have it clicked already?!
So yeah, ticked the box and are happily native ipv6 now.
There surely can't be that many incompatibilities preventing default adoption of ipv6 these days, can there?
SteamDB helpfully grabs the file which is used to configure the list of relays in the Steam client: https://github.com/SteamDatabase/SteamTracking/blob/master/Random/NetworkDatagramConfig.json They're all listed with IPv4 addresses, so there's no IPv6 connectivity to the relays.
Consider other Steam APIs, like this one: https://partner.steamgames.com/doc/api/ISteamGameServer#InitGameServer You can only pass an IPv4 address to that function, same with lots of other Steamworks APIs.
You mean; besides the fact that a considerable slice of the world-wide web is still stuck on IPv4-only hosting? Or the fact that there's a huge backlog of applications, including many network-connected video-games that simply don't support IPv6, because they bind explicitly only to IPv4 rather than using some kind of abstraction layer to handle it for them. Or maybe that abstraction is codified in a library that ships with the game and is dependent on updates provided by the publisher of the game, rather than the OS vendor? Etc. etc.
Many people keep to IPv4 because they actually really still need it. While most people actually don't even know the difference. Thus the need to adopt IPv6 is only due to the shortage of IPv4 addresses; there isn't actual consumer demand.
That makes IPv6 adoption largely a chicken-and-egg problem.
Largely. The other part of the problem lies in that shortage in and of itself.
The shortage itself is hindering the adoption because the major big-tech players that could construe actual drivers for deep adoption of IPv6 and get hardware vendors and ISPs to upgrade local infrastructure, are simultaneously most often the digital service providers that are hanging on to the biggest as-of-yet-unused blocks of IPv4 addresses. And some, like Amazon, are actively speculating with them - buying and selling and treating them as an alternate form of stock. It's actually in those companies' best financial interests to keep that market of speculative acquisition and sale of IPv4 blocks alive for as long as possible. And that means keeping IPv6 adoption marginalized.
the baddly stuff about ipv4 is cgnat, that delays your connection and put an equipment between you and the server, it of course will delay your connection, could be 4~6ms, but still a delay, and if the cgnat/nat machine gets busy, your connection will be really bad, about your problem with ipv6, that's could happen, but its a simple stuff that could be solved by your ISP
cgnat and nat can still be used on both ipv4 and ipv6 - nat is not tied to the protocol itself, and nat isn't always a bad thing as it can help protect your internal network from outside attackers
Routing-solutions at the ISP level are anything but simple.
Moreover; good luck getting any consumer-grade ISP to change anything infrastructure-wise wrt ping or latency. You'll be lucky if your complaint even makes it through first-line support without being given the have-you-tried-turning-it-off-and-on-again run-around for three days straight.
i'm the manager from multiples ASNs (or ISPs) and that's how i'm saying that, sometimes ISPs don't care about ipv6 routing because there's almost nothing with ipv6 traffic to manage, so the demands brings the offer, if i have more ipv6 networks to care about, i will care about.