+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Proposal :: Startup params & IP bind (/thread-1952.html)
Proposal :: Startup params & IP bind - nte - 05-18-2015
My first post so Hello everyone!
Let me start by saying that I am not a MC player rather a backend sys for a community/small hosting so my point of view is mainly focused on aspects in this area. I've been approached over the last year countless of times to put up a MC server but never liked the idea running java along side other games due overhead/nor setting VPS/Box since there's always cost involved (time/money) so in my mind idea has to be approached rationally. I've been following this project for some time now and I like what I see.
To put this in some perspective this is where I am currently at. I decided to set a sandbox and put a instance of this project up and see what our community thinks about it. If they will like it I will put a fully fledged server up at which point I will be able to provide feedback as well as (if time allows it) contribute back to the project with core patches. Since I do not play MC I at this point cannot provide any suggestions regarding game as that feedback will be gradually provided to me by our testers, I do miss few functions on my end of things, namely:
- IP binding
We run multiple games on a box and have a IP pool assigned to it so it would be nice if I would be able to bind the game to a single IP. This sort scenario is useless for default MC due the fact it's best suited in its own environment (VPS/Box) thus gets its own IP but this project is a different beast in that perspective (no overhead involved just sorting out libs) so it allows running multiple instances on a single box (assuming resources are there..). Most of our potential clients would run small servers (5/10 users) so a decent box could easily run few instances without being converted to VPS box thus avoid some of the overhead introduced with such a setup.
My main problem in this area is basically that currently the sandbox instance is listening on all the IPs and since I wrote our game panel that kinda works against us- panel itself just checks all the ports in use (in DB) on a targeted IP when new game is deployed and assigns one that is not in use. So basically ability to bind to a single IP solves such scenarios where theoretically certain setups- like mine, could end up in deploying a server with assigned port that overlaps it. I currently solved this by assigning high port which shouldn't be reached any time soon but that's not really a solution merely a workaround.
- Startup parameters
I went over wiki (briefly, I admit) but could not find any information if it's possible to pass parameters when starting an instance? If it is, I would kindly ask if one can point me to that topic/wiki entry so I can go through it, if not than I would advocate about rethinking to put such a feature in. If such a feature is not yet implemented my suggestion would be that is prioritized over any config entries as that would solve few problems hosters face, problems like slots, ports, IP (if/when implemented) overriding by users on a multi host setup.
I hope you will consider about implemented aforementioned features but if not, I will understand. In either case, thank you for taking your time to read this.
Nate
RE: Proposal :: Startup params & IP bind - worktycho - 05-18-2015
Startup params is currently under development, with the initial development in PR #2019.
RE: Proposal :: Startup params & IP bind - NiLSPACE - 05-18-2015
Hello and welcome to the forum.
It should be possible to only bind to a single IP, but don't quote me on it. Xoft probably knows how hard it is to implement it, so we'll have to wait for him to respond ^^. The only problem I can think of is that plugins are also able to bind a port. Should they also only use that IP?
We currently have 2 startup parameters, but they are for debug purposes only. But since it was requested a few days ago worktycho is now working on implementing commandline arguments.
RE: Proposal :: Startup params & IP bind - LogicParrot - 05-18-2015
Welcome
Disclaimer: I am the youngest of the pack, I became a collaborator very recently, so if the info is inaccurate, the others will probably enlighten you more.
The command-line parameters request popped up recently, and @worktycho has been working on it. You can follow it here and here. He might also respond here and tell you how it's going. There's some code pushed by him, but it isn't merged with MCServer yet.
Edit: currently we just have a MASTER branch.
RE: Proposal :: Startup params & IP bind - bearbin - 05-18-2015
Most of the builds are kept on the buildserver: http://builds.cuberite.org/
There are some testing builds there. I haven't enabled ARM builds because it needs manual configuration, and there are no stable builds as we haven't had our first stable release yet.
RE: Proposal :: Startup params & IP bind - xoft - 05-18-2015
I see most of your questions have already been answered, so I'll just tackle the IP binding. Currently that is not possible, but it shouldn't be too difficult to add in a very rudimentary form. There's a question of plugins, though - we have API available to plugins that can make connections, both client and server, to the outside world, using TCP and UDP. We could enforce the same IP binding globally for the plugins, too, or we could make it a separate setting (server binds to IP1, plugins bind to IP2). Does that scenario make any sense at all from the hosting point of view, or are we allowed not to bother?
Also we currently bind to both IPv4 and IPv6. If there is an interface specified for binding, I fear that it might force only one of those to be used. Is that acceptable?
Finally, do we need to provide the possibility of multiple specific IPs bound to a single server? Say, for example, you want it to listen on IP1 and IP3, but not on IP2. This would become rather ugly to code.
RE: Proposal :: Startup params & IP bind - nte - 05-18-2015
Hello again,
Thank you for all your answers so far, too avoid spawning a novel I will address them in a go.
I've spawned a local virtual image and basically cloned the production setup and build the master there, then just moved it to production server and sorted the libs and it's running fine for 4 days now. We had no crashes so far besides some downtime due tweaking configs per tester's request and doing restarts. I am fully aware of the overall state project is currently in so my current targeted branch is stable, mainly to get the feeling and ins and outs around the whole thing. Current plans are to stay on stable branch and if proven stable with positive feedback then push this to public while spawning another instance for internal development, at that point I will switch internal to Testing branch and probably get acquainted with the project's code and hopefully find a bearing in it all and than contribute back if I come up with anything worth mentioning- note: programming is my Hobby not my work so experience my vary.
In either case, I will check the links you all provided and then if needed, post/get involved there, thanks again!
P.S. @NiLSPACE
It is possible to bind to single IP by tweaking the NAT (i.e. iptables) but it would still cause problems on multi setup when all IPs use same port (convenient for clean URL hosting (non url:port)) so it's not really a solution rather just a workaround. =)
RE: Proposal :: Startup params & IP bind - LogicParrot - 05-18-2015
Wait, wait, "master" is the *least* stable. We don't have a stable yet.
Mis-read something, nevermind.
RE: Proposal :: Startup params & IP bind - nte - 05-18-2015
@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.