Hm 300ms.
Meni se to zdi malo malo, vsaj glede na to, da če pingaš kakšen server na drugem koncu sveta kaj hitro prideš do 300 ms pinga. 350ms pinga imam recimo do kame.net pa sem na native dualstacku.
Drug problem vidim tudi pri 3G povezavah – tam so latence vedno dokaj visoke. Torej se bojim, da bo hitro prišlo do nezaželenega fallback-a na IPv4.
Pomojem bi bila bolj smiselna vrednost okoli 500ms.
Razen če tu dejstvo da ima IPv4 zahtevek potem še 300ms zakasnitve kaj dosti vpliva na končni rezultat “tekmovanja” med IPv6 in IPv4?
Hm 300ms.
Meni se to zdi malo malo, vsaj glede na to, da če pingaš kakšen server na drugem koncu sveta kaj hitro prideš do 300 ms pinga. 350ms pinga imam recimo do kame.net pa sem na native dualstacku.
Drug problem vidim tudi pri 3G povezavah – tam so latence vedno dokaj visoke. Torej se bojim, da bo hitro prišlo do nezaželenega fallback-a na IPv4.
Pomojem bi bila bolj smiselna vrednost okoli 500ms.
Razen če tu dejstvo da ima IPv4 zahtevek potem še 300ms zakasnitve kaj dosti vpliva na končni rezultat “tekmovanja” med IPv6 in IPv4?
300ms je prednosti, kar pomeni, da bi moral imeti IPv6 za 300ms slabsi kot IPv4 da bi ta prevladal.
Ce pa IPv6 ne dela je prvi “hit” 300ms + IPv4 RTT, vse ostalo pa gre po IPv4.
Smart, is it?
TCP stacka seveda ne moreš popraviti ker je Socket API polomljen.
http://blog.ioshints.info/2009/08/what-went-wrong-socket-api.html
Lahko bi popravili kakšno knjižnico, teh je pa verjetno malo morje (pa še vsak programer si je napisal svojo).
eh, vse se da… With sufficient thrust, pigs fly just fine. (RFC1925) 😀