Quote:
Originally Posted by Synx7
pushedx, would be cool if you can update the redirection IP for support also IPv6 addresses. Soon we are going to change it and new servers will have that kind of IP.
|
Well there's a couple of things to understand here.
Right now sro_client uses IPv4. The redirect detour is setup for IPv4 addresses only. Making sro_client to connect to an IPv6 address is possible, but would require hooking a lot more Winsock functions and changing them over. For example, see

for some code comparison of IPv4 to IPv6.
So until Joymax updated all their server code + client code to IPv6, then updated host names and what not, there's no real need to update the redirect to support IPv4. When they finally do update, then the code can be tweaked a little to support it, but it'd not be possible to do until I actually had the IPv6 address they were connecting to. Since the addresses are in a different format now, the entire detour logic has to be reworked.
If you wanted to run an proxy on an IPv6 server, it'd be possible to make the client connect to it, but your outgoing connecting to Joymax would have to be through an IPv4 socket, which would not be possible unless your server had both an IPv4 and IPv6 IP. If it had an IPv4 address, then there would be no need for the IPv6 interface in that case.
If you wanted to run an emu on an IPv6 server, then that's the only case right now that you can't do but it's not something I'd add to the loader. Simply because its not a Silkroad problem but a "how do I connect an IPv4 program to an IPv6 server".
Instead, a generic solution could be made for that case. You'd have your normal IPv4 redirection via detour but rather than connect to a server, you'd connect to a local proxy that had an IPv4 accept pending and would make an IPv6 connect to your destination server. In essence, this is just tunneling. The local proxy program would than just pass data back and forth across the sockets and it's all seemless.
With that route, all programs would be supported, and not just Silkroad.
However, the big issue for now is that until IPv6 is officially adopted and everyone makes the transitions to it, sometime in 2012 for the US, there's not much you can do if you are stuck on IPv4. (should checkout
World IPv6 Day this year though) So I have no way to really test IPv6 functionality if I wanted to across the net per se until my ISP updated. For local testing, I'd have to go through and get my PC (XP) setup for IPv6 and then run a local server to test, but that doesn't do much good for everyone else since they would have to setup and configure their PCs similarly but only for the sake of being able to connect locally to themselves, something they can already do with IPv4.
To make a long post short, there's nothing I can do about this anytime "soon". In addition, all development for this loader has already ended, so by the time IPv6 is actually needed, this project would be long dead anyways ^^.