@xoft - Saw your post after I submitted.
IPv4 and IPv6 can easily be used the same time since both utilize independently. As for multiple IPs, I currently cannot imagine any scenario where such a thing would be needed since if that is the case, then one could easily just listen on them all as it is now. Single IP binding is mainly needed to solve TLD issues and port race conditions. While race conditions can partially be solved with a workaround TLD issues cannot. Consider following example:
TLD (trivial problem)
We have two clients, both clients buy domain and point it to a box. If servers are ran on same box we can assign each their own IP and have their servers use default MC port, thus both only need to advertise their domain (my-mc-server.com) while in current scenario one will have to advertise domain:port (my-mc.server.com:custom-port) since there is no way to use default port as it is already in use by first server.
Race condition (real problem)
Experience shown that Clients have tendency to use online tutorials and blindly copy-paste and overwrite their configs. Most of tutorials use default ports so in current scenario we add custom port and client unintentionally overwrites their config with default and tries to use default port, which by the fact he has custom port is already in use..that results in tickets and problems that could easily be avoided. Same applies for clients that intentionally try to use different port than one assigned by hoster (common practice but mainly used for increasing slots although ports- when non standard are assigned, are no exception either..).
I hope this reasoning explains why IP binding would be useful.
-------------------
Suggestions
- I grabbed the source and really briefly went through it. If my understanding is right you could easily parse ipv4 and ipv6 parameters (once they are implemented) to Socket.cpp so server binds it self to that IP upon socket creation. Granted, I at the moment have no understanding nor time to dig deeper so further alterations may be required for plugins but in that sort of scenario, I assume whole process would just be repeated in a similar way?
- As for params, a simple prefix (i.e. "--<arg1> <arg2>") scheme could be implemented where values are parsed to structure on a run time and a simple method is created which sole purpose is to be used as a wrapper on startup/world loading at all file readings..where every command in any file is checked against structure and if found in it, it uses value in structure rather than one that file is trying to set..that would for the most of the things solve the precedence level/overriding attempt as well as since params have to be explicitly added it is safe to assume one doing it, understands the impactions on the game and knows how to solve it, if it doesn't start. Granted, runtime scheme needs polishing to deal with more than 2 parameters or "" but one doing it, probably has solid understanding how engine works so should already know what is needed in order to implement it properly.
IPv4 and IPv6 can easily be used the same time since both utilize independently. As for multiple IPs, I currently cannot imagine any scenario where such a thing would be needed since if that is the case, then one could easily just listen on them all as it is now. Single IP binding is mainly needed to solve TLD issues and port race conditions. While race conditions can partially be solved with a workaround TLD issues cannot. Consider following example:
TLD (trivial problem)
We have two clients, both clients buy domain and point it to a box. If servers are ran on same box we can assign each their own IP and have their servers use default MC port, thus both only need to advertise their domain (my-mc-server.com) while in current scenario one will have to advertise domain:port (my-mc.server.com:custom-port) since there is no way to use default port as it is already in use by first server.
Race condition (real problem)
Experience shown that Clients have tendency to use online tutorials and blindly copy-paste and overwrite their configs. Most of tutorials use default ports so in current scenario we add custom port and client unintentionally overwrites their config with default and tries to use default port, which by the fact he has custom port is already in use..that results in tickets and problems that could easily be avoided. Same applies for clients that intentionally try to use different port than one assigned by hoster (common practice but mainly used for increasing slots although ports- when non standard are assigned, are no exception either..).
I hope this reasoning explains why IP binding would be useful.
-------------------
Suggestions
- I grabbed the source and really briefly went through it. If my understanding is right you could easily parse ipv4 and ipv6 parameters (once they are implemented) to Socket.cpp so server binds it self to that IP upon socket creation. Granted, I at the moment have no understanding nor time to dig deeper so further alterations may be required for plugins but in that sort of scenario, I assume whole process would just be repeated in a similar way?
- As for params, a simple prefix (i.e. "--<arg1> <arg2>") scheme could be implemented where values are parsed to structure on a run time and a simple method is created which sole purpose is to be used as a wrapper on startup/world loading at all file readings..where every command in any file is checked against structure and if found in it, it uses value in structure rather than one that file is trying to set..that would for the most of the things solve the precedence level/overriding attempt as well as since params have to be explicitly added it is safe to assume one doing it, understands the impactions on the game and knows how to solve it, if it doesn't start. Granted, runtime scheme needs polishing to deal with more than 2 parameters or "" but one doing it, probably has solid understanding how engine works so should already know what is needed in order to implement it properly.