J0nnJ0nes
|
|
« on: March 31, 2011, 09:02:45 AM » |
|
The source from the SourceForge git repository compiles properly now. However, I don't think the dedicated part works. I copied and pasted the make -j3 DEDICATED=1 right into the terminal, but when I run the binary that is made, it's no different than the regular game binary (as far as I can tell...). Is it supposed to be that way, or is it supposed to be a console that I can type in everything?
|
|
|
Logged
|
|
|
|
Tapio
Newbie
Posts: 8
|
|
« Reply #1 on: March 31, 2011, 11:09:30 AM » |
|
Are you using the CMake build system? In that case, you need to enable the server building either using ccmake or similar, or setting the flags on command line: cmake -DBUILD_DEDICATED_SERVER=YES -DBUILD_MASTER_SERVER=YES .. After which the servers will be built as separate binaries with plain make -j3 without extra parameters.
|
|
« Last Edit: March 31, 2011, 11:11:02 AM by Tapio »
|
Logged
|
|
|
|
Cybertron
Coldest Developer
Administrator
Full Member
Posts: 77
|
|
« Reply #2 on: March 31, 2011, 08:54:51 PM » |
|
Yeah, sorry, I forgot to update the dedicated server page with the new instructions. Should be fixed now.
It also occurs to me that this is probably what you meant about a lot of errors in the other thread. I'm guessing the dedicated server wasn't building correctly in the last svn revision, so that makes more sense.
|
|
|
Logged
|
|
|
|
J0nnJ0nes
|
|
« Reply #3 on: April 01, 2011, 06:33:10 AM » |
|
Awesome! Thanks! I can confirm that it compiled fine, although you might wanna mention somewhere that it makes a binary for the client as well, with the options so nobody mistakenly compiles the game twice thinking they're completely separate. In other words, "If you ever want to host a server, in addition to playing on other servers, compile with these options." I'm not sure whether it shows up on the master server list, as it didn't show up when I wanted to join my own server, but I was able to connect to my IP directly. This has happened before when I've hosted other games, but I could confirm my server showed up because of web page server lists, such as the following: =1=, =2=, =3= . I'm not sure how to confirm it, so I'll probably try to leave the server up during this weekend, as I'll be busy with other things anyway, and it seems to require minimal resources to host. Also, I'm guessing the master server binary is there for testing? or backup? Is there a current master server running somewhere?
|
|
|
Logged
|
|
|
|
Cybertron
Coldest Developer
Administrator
Full Member
Posts: 77
|
|
« Reply #4 on: April 01, 2011, 10:38:46 PM » |
|
I added a note about the build process. Although it wouldn't hurt much to do multiple builds as nothing would really happen for the second one. There was a network configuration issue on the master server that was making it fail to respond to traffic from behind a NAT. That's fixed now, so when you start the client you should get a bunch of messages in the console and log that list all of the servers that the master server knows about (most of them won't be running at any given time though). If your IP is in there then it should show up in the server list. I should mention that I don't see any running servers in the list right now though, even after fixing the master server problem. The master server build stuff is only included because it uses some of the same code as the rest of the game so it makes sense to use the same build system. Nobody except me should ever need to build it, unless they're working on the master server itself.
|
|
|
Logged
|
|
|
|
J0nnJ0nes
|
|
« Reply #5 on: April 03, 2011, 03:34:36 AM » |
|
That is strange. I have yet to see a "Received server announcement for" for my IP. I even tried opening the extra ports, but no change. And I don't see my server on the list, only a "Coldest Testing Server" (Ping 100-200).
With the update, I did get a server.bin , but it gives me an error:
server.bin: error while loading shared libraries: libboost_filesystem-mt.so: cannot open shared object file: No such file or directory
That file was not included in my installation of libboost-1.41.0, but it IS in the lib directory of the game directory.
I'll try to re-download and recompile everything (may be unnecessary, but as it's pretty quick, and quicker than a response, why not ;p).
|
|
|
Logged
|
|
|
|
J0nnJ0nes
|
|
« Reply #6 on: April 03, 2011, 06:20:10 AM » |
|
Woah! Major problem found! I managed to get the server.bin working by copying all the necessary libs into the same directory as the bin, and seemed to run ok, but before I even checked if the server was on the master server's list, I found a problem. I tried to end the program with CTRL+C and even closed the terminal, but on gkrellm (internet + system monitor), I noticed I was still receiving a large number of packets, even though nothing else was running (even checked processes). I even restarted the computer, but the packets received were still there.
The only thing that worked was restarting my router. This is a problem. I don't want to try that again, so I'll hold off on hosting till stuff like this can't happen anymore... losing all control over it like that is scary, and maybe even dangerous, as far as I can tell.
|
|
|
Logged
|
|
|
|
Cybertron
Coldest Developer
Administrator
Full Member
Posts: 77
|
|
« Reply #7 on: April 03, 2011, 11:25:05 AM » |
|
When you ran server.bin, did you run it directly? There should be a server script that sets up LD_LIBRARY_PATH so it will use the included libs, and that's how the server needs to be started in the packaged version. As for the other problem, the only possibility that I can come up with is that the master server was trying to send something to you at the same time you ended the server and it continued trying to send even after the server was stopped, but even in that case it can't send packets more than once every half a second because it sleeps for that long in between sends. The other possibility would be a client trying to connect, but if it's not showing up in the server browser then I don't see how that would happen either (and that also shouldn't be able to generate that much traffic, but bugs do happen ). I guess the only thing I can say is that if it happens again you could grab a wireshark dump of the traffic and send it to me. I should be able to figure out what's causing it from that. Otherwise I'm not sure how much I can do - I haven't seen the problem myself and at this point I can't come up with a plausible explanation for how it would have happened. Actually, I guess there are a couple of other things I would be curious to know too though. First, how much traffic are we talking about? A few kbps or maxing out your connection? Were you running the client at the same time this happened? And as it appears you are on Linux, did you download the updated -bin file? Unfortunately I broke the updater in new and exciting ways last release so it won't properly update the coldest.bin file by itself. I'm not positive what effect that might have, but I'm pretty sure it wouldn't be good.
|
|
|
Logged
|
|
|
|
Cybertron
Coldest Developer
Administrator
Full Member
Posts: 77
|
|
« Reply #8 on: April 03, 2011, 11:30:04 AM » |
|
Oh, and I should probably mention that the Coldest Test Server is something I set up on an Amazon EC2 instance. It turns out they will give you a year of their smallest image free, so I figured I would take advantage of it to set up a test server. We'll see how it works as I think it will be a bit constrained on memory and CPU, but it's still a good bit faster than the server the site is hosted on and there isn't a "no game servers" clause in their AUP.
|
|
|
Logged
|
|
|
|
J0nnJ0nes
|
|
« Reply #9 on: April 04, 2011, 04:33:27 AM » |
|
I was trying to run the binaries directly that time (having copied the static libs into the same directory), but I've tried it again with the scripts now, and I can confirm the same thing happens (finds the libs correctly, but still the connection spam). I was NOT running the client at the same time, or anything else for that matter, not even a browser.
I receive a pretty constant 684 bytes per second, with occasional spikes to ~1.7 kbytes and reductions to 300 kbytes. Starting another server doubles those numbers. However, I did find that typing quit, in the terminal running the server, exits properly (no more connection spam). It seems only CTRL+C or closing the terminal while the server is running causes the problem.
Wireshark seems to be missing a WireTap library ... or I'm thinking misplaced.
|
|
|
Logged
|
|
|
|
|
J0nnJ0nes
|
|
« Reply #11 on: April 05, 2011, 10:09:15 AM » |
|
Then, I'll try to find a way to get Wireshark to work, maybe even a pre-compiled one. That or something similar. Then, in the mean time, you have no way to test the "improper server exit" I mentioned?
|
|
|
Logged
|
|
|
|
Cybertron
Coldest Developer
Administrator
Full Member
Posts: 77
|
|
« Reply #12 on: April 05, 2011, 07:24:13 PM » |
|
Well, the thing is that there shouldn't be any difference. In both cases the same code gets run to shut things down. The one exception might be closing the terminal window because that can kill the process with extreme prejudice and might not let it run cleanup code, but just ctrl-c shouldn't be a problem. Until I can see what the traffic is I'm pretty much in the dark as to why it behaves differently.
|
|
|
Logged
|
|
|
|
J0nnJ0nes
|
|
« Reply #13 on: April 06, 2011, 11:58:51 AM » |
|
OMFG! I can't believe it! It turns out that it has NOTHING to do with the server! It's the client, and it always was. I just didn't realize I ran the client at least once each time (I ran it so many times to try to figure things out, I could have sworn I didn't run the client!). The client does not exit properly when you click "Exit". It seems recent, as I never remember the client doing this in the prior versions (my memory may still be faulty though to due exhaustion... be warned ). The files I captured with Wireshark are here: http://www.multiupload.com/H9DPUE8ZVX
|
|
|
Logged
|
|
|
|
Cybertron
Coldest Developer
Administrator
Full Member
Posts: 77
|
|
« Reply #14 on: April 06, 2011, 07:09:14 PM » |
|
Ah, now that makes more sense. It was the master server sending the traffic (and don't worry, it will time out and stop sending eventually but it will take around 40 minutes by my calculations), but the bug was in the client. It was ignoring the ack packet so it kept sending version requests and the master server kept responding. Then when the client exited, the master server still had the last request and continued trying to respond to it. I've pushed a fix to the Git repo and I'll get a fixed build out to the update server too. Thanks for your help with this.
|
|
|
Logged
|
|
|
|
|