| 00:22.06 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:22.06 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.14 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19953 |
| 00:22.07 | *** mode/#bzflag [+v infobot] by ChanServ |
| 02:54.52 | *** join/#bzflag Juesto (~nick@rev190-105-167-003.pccp.net.ar) |
| 03:55.13 | *** join/#bzflag Juesto_ (~nick@190.194.204.95) |
| 10:04.43 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 10:04.43 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 12:50.37 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 12:54.49 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 13:02.40 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 13:02.41 | *** mode/#bzflag [+v BulletCatcher] by ChanServ |
| 13:42.49 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 13:43.36 | *** join/#bzflag RoscoePColtrane (~flash@c-71-205-162-253.hsd1.co.comcast.net) |
| 13:57.11 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 14:19.21 | *** join/#bzflag Juesto (~nick@190.105.167.3) |
| 14:58.33 | *** join/#bzflag Juesto_ (~nick@190.194.204.95) |
| 16:34.18 | JeffM | seriously... that's what he comments on? |
| 16:35.39 | JeffM | limiting yourself to a single packet per message may bite you in the ass later, just FYI |
| 16:35.57 | JeffM | the protocol is designed to allow TCP messages to span packets. |
| 17:01.21 | JeffM | ahh he commented on them all |
| 17:14.31 | JeffM | blast007: if you'd like me to write up more detailed notes on any of those items, like shot IDs and shot limits, just let me know. |
| 17:18.23 | blast007 | JeffM: okay. for now I was just trying to get them all in as issues. I plan to add some comments of my own to some of them. |
| 17:19.03 | JeffM | yeah, whenever you want |
| 17:19.34 | JeffM | get some comments, then we can make a page for the complex ones with more details based on the comments. |
| 17:19.43 | JeffM | with pictures if needed :) |
| 17:20.29 | blast007 | for instance, I too was going to comment against the random UDP port |
| 17:21.05 | JeffM | heh |
| 17:21.13 | JeffM | yeah I don't think random was a good word |
| 17:21.20 | JeffM | I had kinda forgot I sugested that |
| 17:21.38 | blast007 | and I guess I wasn't against random, but against bzfs deciding what port to use |
| 17:22.32 | blast007 | does the OS network stack already handle UDP port assignment? if so, I'd rather just keep on using that |
| 17:23.37 | JeffM | ok, we arn't talking about the outbound port the client sends on |
| 17:23.42 | JeffM | that's handled by the OS |
| 17:23.44 | JeffM | that stays |
| 17:23.50 | JeffM | this is the inbound port the client sends to |
| 17:24.01 | JeffM | right now it's hardcoded to be the same as the TCP port |
| 17:24.08 | blast007 | oh, yeah, I don't like that |
| 17:24.17 | JeffM | I just want the proto to tell the client "use this UDP port" |
| 17:24.31 | JeffM | even if the default server always sends the same port as TCP |
| 17:24.38 | JeffM | I just dont' want it hard coded :) |
| 17:25.25 | blast007 | what advantage does that provide? |
| 17:26.07 | JeffM | 1) it lets the server configure a different UDP port if it wants to |
| 17:26.34 | JeffM | 2) the UDP port would be unknown with out connecting to TCP first, so a flood attack can't JUST use the list server |
| 17:27.06 | JeffM | 3) it could allow the server to allocate multiple inbound UDP receive sockets so that not all players are spaming a single UDP socket |
| 17:27.22 | JeffM | if threading is used on the server 3 becomes a good thing. |
| 17:28.06 | blast007 | with UDP, does a single process end up taking control of a port like it does with TCP? |
| 17:28.43 | JeffM | yeah, it's basicly a single socket, like the TCP listen socket, it just gets a BUNCH Of messages |
| 17:28.51 | JeffM | UDP is connectionless, so there is only one. |
| 17:30.01 | blast007 | what I'm meaning is if I run multiple servers, are they going to potentially use the same UDP ports at the same time for different clients? or is that not possible? |
| 17:30.08 | JeffM | adding it to the proto just gives you more options later, and the ability to do networking experiments, with out changing proto just for that. |
| 17:30.30 | JeffM | with the way bzfs is currently writen that would not be possible |
| 17:30.42 | JeffM | it assumes all connections on a single UDP port go to the game it's running. |
| 17:31.20 | JeffM | if you allowed the server to specify the UDP listen port, the second instance would fail to open the UDP listen socket because the socket was already open |
| 17:31.27 | JeffM | it's exactly the same as the TCP listen socket. |
| 17:32.27 | JeffM | and from a buffering standpoint I don't think you'd WANT to have multiple servers all going to a single UDP port, the idea is to let a single server instance use multiple ports to get more thruput. |
| 17:33.59 | JeffM | for an iniital implemntation, I'd add a long to the UDP request the server sends for the port, and have BZFS init it to the TCP port. |
| 17:34.07 | JeffM | that way nothing has to change in configs |
| 17:34.13 | JeffM | and everything works the way it does now. |
| 17:34.28 | JeffM | but it allows expirmentation with server stuff later, using existing clients. |
| 17:34.55 | JeffM | the problem with networking testing using branch clients is, nobody has them :) |
| 17:49.40 | JeffM | at least tim is engaging in discussion :) |
| 17:54.15 | JeffM | resists the urge to add the port and create a pull request |
| 20:12.45 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 20:14.40 | blast007 | from a firewall perspective, how does it work? is it gonna have a pre-defined range of ports? |
| 20:20.06 | JeffM | optimially, yes. the server would host TCP on 5154 and then TCP on 5160 to 5180 or whatever it wanted. |
| 20:20.36 | JeffM | and the server also knows what port services what players. |
| 20:20.51 | JeffM | so if it gets messages for the wrong player, it's trivial to ignore. |
| 20:21.00 | JeffM | the random security byte does that too. |
| 20:21.11 | blast007 | does each server pick just one port? |
| 20:21.17 | JeffM | no no no |
| 20:21.32 | JeffM | so lets say you had 3 servers, and were going to allocate 30 ports per server. |
| 20:22.16 | JeffM | server 1 = TCP 5154, UDP 10100 - 10130, server 2 = TCP 5155, UDP 10200 to 10230, etcc.. |
| 20:22.21 | JeffM | IF you wanted to go that round |
| 20:22.23 | JeffM | route |
| 20:22.28 | JeffM | maybe there is no benifit |
| 20:22.36 | JeffM | who am I to know :) |
| 20:23.04 | blast007 | I don't think there's enough benefit to offset the configuration difficulty |
| 20:23.13 | JeffM | I'd not make that config the defualt |
| 20:23.24 | JeffM | by default I'd make it do the same as TCP |
| 20:23.25 | blast007 | makes it harder to do stuff like a wireshark capture/analysis too |
| 20:23.44 | JeffM | those are special cases |
| 20:24.02 | JeffM | and don't you WANT to make it harder for hackers to wireshark? :) |
| 20:24.18 | blast007 | they weren't |
| 20:24.26 | JeffM | true they have the source |
| 20:24.27 | blast007 | other way around |
| 20:24.48 | blast007 | I was using wireshark to analize a tcpdump from the server to see what was being sent to crash/corrupt a server |
| 20:25.15 | JeffM | I was just trying to think of ways to make it harder for UDP attacks to affect a running game. |
| 20:25.35 | blast007 | wireshark isn't a protocol injection/manipulation tool, it's capture and analysis |
| 20:25.37 | JeffM | if the server supported multiple ports, it should route non attack traffic to other ports. |
| 20:25.56 | JeffM | or an attack would not affect all the players, just those on that port |
| 20:26.13 | JeffM | and the server could choose to not use ports under attack for new connections. |
| 20:26.18 | JeffM | that was the goal |
| 20:26.57 | JeffM | tim's wrong about a single port being effectively unlimited, if it was then the current UDP attacks would not be a problem, and they ARE |
| 20:27.11 | JeffM | at least with my understanding |
| 20:28.06 | JeffM | just doing the security short will save a lot, it'll make it more trivial to ignore a packet. |
| 20:28.19 | JeffM | and thats what you want, to spend the least amount of time dealing with BS data |
| 20:29.21 | JeffM | By using multiple ports my hope was to spin attacks off to basicly it's own thread, because the port would not be used for other connections. |
| 20:29.54 | JeffM | also the UDP connect message can be sent anytime, so you could easaly tell real clients to change UDP ports on the fly |
| 20:36.46 | blast007 | it's trivial to send enough traffic at a server that it doesn't matter what port they're hitting |
| 20:37.13 | JeffM | k |
| 20:37.24 | JeffM | then most of that is moot |
| 20:38.01 | blast007 | I saw attacks exceeding 2Gbps a couple times |
| 20:38.17 | JeffM | ok, so redo bzflag to where everyone connects to a MS one drive folder. |
| 20:38.26 | JeffM | each player uploads a file and edits it with the current postion |
| 20:38.40 | JeffM | and each player then reads those files to get the positions of eveyrone else |
| 20:38.54 | JeffM | change the files to append and you've got recording! |
| 20:41.10 | blast007 | one thing I'm looking forward to is per-second billing at Digital Ocean, which is supposedly coming this year |
| 20:41.36 | blast007 | that could lead to some cool things like on-demand instances being spun up to run a map |
| 20:41.58 | JeffM | doen't AWS do that already? |
| 20:42.08 | blast007 | yeah, but that's Amazon |
| 20:42.20 | JeffM | ummm ok |
| 20:42.34 | blast007 | Amazon/Google/Microsoft doesn't have simple pricing |
| 20:42.41 | JeffM | ahh |
| 20:42.50 | blast007 | they all charge for bandwidth too, and it's per region and stuff... |
| 20:43.27 | blast007 | and I think their systems tend to be more expensive anyway |
| 20:44.13 | JeffM | sure, and probably arn't setup as a normal VM, but a service component written in some odd language :) |
| 20:44.38 | blast007 | EC2 should be a normal VM |
| 20:44.46 | JeffM | ahh |
| 20:45.08 | blast007 | I think Google's equivilent is Compute Engine |
| 20:45.13 | JeffM | so you'd just use the API to spin up a VM from a saved image, have it check with a cenral site for config and stuff, then load up bzfs? |
| 20:45.25 | blast007 | yeah, proably |
| 20:46.47 | blast007 | that kind of thing would be most useful if we went away from the "a server hosts a specific map and runs all the time" kind of design and moved to an on-demand matching kind of system |
| 20:46.57 | JeffM | yes |
| 20:47.00 | blast007 | matchmaking* |
| 20:52.16 | blast007 | example of the pricing difference: Google Compute Engine: a shared CPU core, 0.6GB RAM is $13.80/month, and I don't think that includes bandwidth, and I'm unclear what kind of local storage that provides. Digital Ocean: 1 core, 1GB RAM, 25GB disk, 1TB transfer, $5/month :) |
| 20:52.40 | JeffM | how fast is the core? |
| 20:52.57 | JeffM | I used to use DO they were pretty good |
| 20:53.08 | JeffM | ended up going to some cheaper places because I didn't do much with them |
| 20:53.31 | blast007 | I think with our current code we'd probably run out of RAM before the CPU was overly taxed |
| 20:54.00 | JeffM | how much ram does an average bzfs instace use? |
| 20:56.10 | blast007 | mine are using around 40MB when empty |
| 20:58.30 | JeffM | that seems high |
| 20:59.03 | JeffM | could benift from some profiling maybe? |
| 20:59.40 | blast007 | probably |
| 20:59.53 | JeffM | is the map super complex? |
| 21:00.17 | blast007 | these have been running for a while, and they also have a badword list, which I think makes it eat up a bit more |
| 21:00.30 | JeffM | ahh yeah that'd be a decent chunk of cached data |
| 21:00.45 | JeffM | I was just running through my head what kind of data is cached at startup |
| 21:01.17 | JeffM | map, worldDB, bzdb and not much else. but a large badword list could also do it |
| 21:01.20 | JeffM | how big is the list? |
| 21:02.04 | blast007 | the decks server is 31MB, ratsnest (a complicated map) is sitting at 44MB, but ratsnest is also played on a lot |
| 21:02.21 | JeffM | the logs should not be stored in ram |
| 21:02.33 | JeffM | flag history is all you'd get right? |
| 21:02.58 | blast007 | well, I'm thinking about memory leaks :) |
| 21:03.03 | JeffM | ahh yeah |
| 21:03.08 | JeffM | that is a posibility |
| 21:04.07 | blast007 | I'm using the english badwords file, but I'm also using the more complicated matching to it's building a big ol' regex to match leet speak and repeated characters and such |
| 21:04.24 | blast007 | so* |
| 21:04.44 | JeffM | I recall libbzflag using about 4o megs for an empty map, and itâs super inefficient on memory |
| 21:05.41 | blast007 | my replay server, which likely has no map loaded right now, is sitting at about 16MB |
| 21:05.55 | blast007 | and that has no badword file |
| 21:06.23 | blast007 | (and only one tiny plugin, serverControl) |
| 21:06.34 | *** join/#bzflag Juest (~nick@unaffiliated/juest) |
| 21:07.03 | JeffM | Iâd be curious to see what it all has loaded |
| 21:07.25 | JeffM | Wonder how to use the memory profiler in 2017 |
| 21:07.29 | Juest | hi |
| 21:07.35 | blast007 | hi Juest |
| 21:08.07 | JeffM | Given what bzfs does I just canât see it taking a large chunk of ram |
| 21:08.32 | blast007 | I think it used to be worse, 40MB is a lot smaller than I remember |
| 21:08.44 | blast007 | it used to climb past 80 or 100 iirc |
| 21:09.27 | blast007 | maybe some of those were fixed during the 2.4.4 cleanups and fixes |
| 21:09.33 | JeffM | Oh wow |
| 21:10.00 | JeffM | How big is the executable? |
| 21:11.03 | blast007 | oh, I also may be running debug builds :) |
| 21:11.34 | blast007 | yup |
| 21:12.00 | JeffM | That will take some more room |
| 21:12.04 | blast007 | so the bzfs bin is 26MB |
| 21:12.15 | JeffM | Means no optimization too |
| 21:12.26 | blast007 | yup |
| 21:12.43 | JeffM | Oh then that isnt too bad for ram use |
| 21:14.42 | blast007 | that's going off the "RSS" column of ps. VSZ is more like 180MB for the replay server, and 200 to 215MB of the others. |
| 21:15.46 | blast007 | RSS = "resident set size, the non-swapped physical memory that a task has used" |
| 21:16.21 | blast007 | VSZ = "virtual memory size" |
| 21:27.23 | JeffM | on windows, debug bzfs is 4.5 megs |
| 21:27.46 | JeffM | but most of the debug info is in another file |
| 21:28.19 | JeffM | the PDB is 38 megs :) |
| 21:35.07 | JeffM | just starting a basic instance of bzfs starts about about 3 megs in the profiler |
| 21:37.59 | JeffM | most of that seems to be curl and ares |
| 21:45.25 | JeffM | yeah publize is the biggest thing in bzfs at startup. |
| 21:46.29 | JeffM | https://usercontent.irccloud-cdn.com/file/O658KGVy/image.png |
| 21:47.15 | JeffM | so yeah, I don't think it should use a ton of memory as it runs |
| 21:47.52 | blast007 | yeah, my info was probably a bit old, and was also based on debug builds |
| 21:48.29 | JeffM | I could see 10 or so megs per instance, not counting code as normal. |
| 21:48.48 | JeffM | + whatever the badwords or other plugins do |
| 21:49.07 | JeffM | that's why I was pondering offloading chat filtering to seperate DB service. |
| 21:49.23 | JeffM | on bad word list and one bad word processor for multiple servers. |
| 21:54.04 | blast007 | with project run servers, we could offload all chat to another service |
| 21:56.18 | JeffM | and map downloads |
| 21:56.45 | JeffM | bzflag as a service |
| 22:36.43 | blast007 | https://developer.github.com/changes/2018-04-25-github-services-deprecation/ and I see no replacement for IRC notifications... |
| 23:04.27 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 23:07.51 | allejo | webhooks can still be used |
| 23:07.58 | allejo | to bots |
| 23:08.12 | blast007 | which means we have to run our own bot now |
| 23:08.32 | allejo | there are those among us who already run stable bots |
| 23:08.48 | allejo | nominates alezakos' boal |
| 23:15.03 | allejo | https://github.com/nodejs/node/issues/20563 node has the same issue, might want to follow that issue to see what they come up with? |
| 23:53.15 | blast007 | JeffM: As for "Add Message to redirect client game connection to another server", what would the uses of that one be? Redirecting someone off a tutorial server after they finish the tutorial? |
| 23:58.14 | JeffM | Yeah, or to a private league match |
| 23:58.50 | JeffM | Have a fun play server for warmup then league plugin redirects them to the actual match instance |
| 23:59.28 | JeffM | If you are going for the spin up/down of instances being able to redirect helps use that more |
