| 00:02.24 | *** join/#bzflag EvilJStoker (jstoker@unaffiliated/jstoker) |
| 00:02.49 | *** join/#bzflag ukiki (ukiki@2600:3c03::f03c:91ff:fe70:30aa) |
| 01:23.24 | *** join/#bzflag infobot (ibot@rikers.org) |
| 01:23.24 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 01:23.25 | *** mode/#bzflag [+v infobot] by ChanServ |
| 08:35.14 | *** part/#bzflag p4ncake_ (~p4ncake@p4ncake.fr) |
| 08:44.18 | *** join/#bzflag aFreshMelon (sid25548@gateway/web/irccloud.com/x-hsxjhzydjhkudvjr) |
| 16:37.10 | blast007 | if I want to require modern HTTPS as of August 1, 2018, is that going to be a problem for anyone? By that, I mean that clients older than 2.4.4 won't be able to get a list or authenticate, and Windows XP with any version would be unable to get a list or auth. |
| 16:40.34 | blast007 | It'd be nice to be able to upgrade my servers, but in doing so would mean that OpenSSL no longer has any ciphers in common with Windows XP. |
| 17:18.58 | JeffM | just pull the trigger, you don't need a year's notice for a community this small |
| 17:26.21 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-bhpufzpjlhmupcdu) |
| 17:31.16 | blast007 | Well, I'd probably wait until then anyway. |
| 17:32.50 | blast007 | Let's Encrypt will offer wildcard certs in 2018 |
| 17:33.24 | JeffM | 1.7% of web hits in 2016 to wikipedia were XP, I think you are good |
| 17:33.29 | JeffM | you may hit maybe 1 person |
| 17:41.14 | blast007 | need to test let's encrypt across multiple servers as well |
| 18:13.58 | JeffM | do you want me to buy you some certs till then? |
| 18:14.57 | blast007 | the cert is good through Aug 23, 2018 |
| 18:15.05 | JeffM | ok |
| 18:15.08 | blast007 | download.bzflag.org is already using LE |
| 18:15.23 | JeffM | they do 90 day certs right? |
| 18:15.27 | blast007 | yup |
| 18:25.18 | JeffM | anyone know what compression method "compress" in zlib uses? |
| 18:25.59 | JeffM | I've got 3 choices in the C# version of ZLIb, DeflateStream, ZLIbStream, and GZipStream.... |
| 18:26.17 | JeffM | the map data is compressed with "compress2" and decompressed with "decompress" |
| 18:29.04 | blast007 | is that useful? http://zlib.net/zlib_tech.html |
| 18:29.45 | JeffM | not really |
| 18:29.53 | blast007 | k :) |
| 18:29.57 | JeffM | I'll have to make a test app that compresses the same data and compares |
| 18:29.59 | JeffM | thanks though |
| 18:30.15 | JeffM | trying to get libBZFlag to be able to build a binary world file |
| 18:36.57 | JeffM | when proto change time comes around, I have some suggestions about message ordering :) |
| 18:37.05 | JeffM | MsgEnter is sent WAY too late |
| 18:37.30 | blast007 | currently it's after the world download, right? |
| 18:37.34 | JeffM | yeah |
| 18:37.39 | blast007 | yeah, I don't like that either |
| 18:37.40 | JeffM | and potenticaly other stuff |
| 18:37.50 | JeffM | all bannable things must be done first ;) |
| 18:37.54 | blast007 | I want to be able to process auth and bans before the world, flags, and BZDB |
| 18:37.59 | JeffM | yeah |
| 18:38.52 | JeffM | also the world info should be pushed, the pull shold only be for download |
| 18:39.04 | JeffM | push out the map name, hash, and URL as one message. |
| 18:39.24 | JeffM | that way the server can just push new worlds. |
| 18:39.38 | blast007 | so, map change without rejoin? |
| 18:40.27 | JeffM | yes |
| 18:40.44 | JeffM | that combined with teh ability to limbo all players would make reconnects very rare |
| 18:40.53 | blast007 | that'd be sick nasty, as the kids say |
| 18:41.07 | JeffM | kids from the 90's? |
| 18:41.38 | blast007 | Probably |
| 18:42.37 | JeffM | I've got all the messages, incuding world getting happening so far but the decompress on the client side fails. |
| 18:42.49 | blast007 | but hey, vinly records are a thing again, so who knows. are zoot suits back in style? |
| 18:42.57 | JeffM | the precompressed data looks correct, but something is probalby wrong with a compression header. |
| 18:43.24 | JeffM | everthing pre-enter happens in a security jail thread |
| 18:44.44 | blast007 | that's with the lib doing the server side? |
| 18:44.58 | JeffM | BZFlag.Game.Server |
| 18:44.59 | JeffM | yeah |
| 18:45.14 | JeffM | networking core is in it's own shared lib |
| 18:45.17 | blast007 | neat |
| 18:45.36 | JeffM | and there is a bzdb lib, a world lib, and a BZW.IO lib |
| 18:51.19 | JeffM | the main idea is to make it be super maintainable |
| 18:51.26 | JeffM | every message is it's own class |
| 18:51.32 | blast007 | hmm... AWS, Google Cloud, and Azure all have a TCP/UDP network load balancer |
| 18:51.48 | JeffM | and the data packer dynamicly allocates buffers and prevents overruns |
| 18:53.22 | blast007 | could those load balancers, in theory, be used to distribute client connections across multiple game server instances (that would share state between each other)? |
| 18:53.41 | JeffM | that backend connection would have to be super fast |
| 18:53.59 | JeffM | but yes,theoreticly you could sync the sate |
| 18:54.00 | JeffM | state |
| 18:54.05 | blast007 | probably just needly complication though, right? |
| 18:54.09 | blast007 | needless* |
| 18:54.19 | JeffM | what is the goal? |
| 18:54.48 | JeffM | to be able to allocate multiple cores to message processing ? |
| 18:54.57 | JeffM | or to have thousands of players? |
| 18:55.08 | JeffM | or to use cheap servers to cluster a larger server? |
| 18:55.16 | JeffM | do you want to ride 2 smaller dogs like a big dog? |
| 18:55.18 | blast007 | oh it'd be more expensive, since it's cloud |
| 18:55.41 | JeffM | if the goal was to split up the resources required for message processing, that could be one way |
| 18:55.51 | JeffM | you could also do it on a single machine with multiple ports |
| 18:56.01 | blast007 | thought was to have something more resiliant for one, that could scale to a larger number of players (and possibly have multiple worlds running) |
| 18:56.23 | JeffM | well you don't need multiple hosts to do that |
| 18:56.28 | JeffM | just multiple cores |
| 18:56.36 | blast007 | at least for the latter two |
| 18:56.52 | blast007 | probably easier and more sane is just spinning up instances on demand |
| 18:56.52 | JeffM | I"ve designed my system to be able to take conencitons from multiple TCP acceptor threads. |
| 18:57.09 | JeffM | you could also add a redirect message to the protocoll |
| 18:57.16 | JeffM | then no need for a load balancer |
| 18:57.35 | JeffM | right now, since bzfs is so stupid, it'd actually be easier to split it :) |
| 18:58.18 | JeffM | in the lib I have now, it would be relativly easy to build a bulk message updater for player packaets to sync 2 servers on the backend and have them basicly be the same "game" |
| 18:58.30 | blast007 | thinking more about situations where the need to switch isn't planned |
| 18:58.30 | JeffM | one would have to arbitrate IDs, but the rest would be pretty easy |
| 18:58.50 | JeffM | so like your game is hosted on 2 nodes, and you need to take one down? |
| 18:58.53 | blast007 | but I suppose it's a silly tank game, not a business critical system :) |
| 18:59.03 | JeffM | and want to redirect everyone to the remaining node? |
| 18:59.28 | JeffM | what level of service inturuption is acceptable? |
| 18:59.37 | JeffM | any kind of handover is going to have some latency |
| 19:00.12 | JeffM | its it more acceptable to send out a redirect packet? |
| 19:00.34 | blast007 | dunno |
| 19:00.43 | JeffM | or are you worried about a case like hardware failure where no outbound messages could be sent from the affected node? |
| 19:00.58 | blast007 | network outages, kernel panic, that sort of thing |
| 19:01.38 | JeffM | yeah in that case you 'd need a gateway |
| 19:01.45 | JeffM | that would add overall latency |
| 19:02.17 | JeffM | does the cloud service offer a latency stat? |
| 19:02.28 | JeffM | most services that would use that don't care about latency but about bandwith. |
| 19:03.09 | blast007 | that's why I was thinking about a distributed server that kept a shared state - a client could reconnect to another node in that cluster and resume where it left off |
| 19:03.36 | blast007 | but I'm overthinking things |
| 19:03.43 | JeffM | sure, so you are ok with individula clients having a reconnect |
| 19:04.01 | JeffM | poissibly but it's a good thing to at least think about. |
| 19:04.17 | blast007 | depends how we see the game working in the future |
| 19:04.24 | JeffM | you could send all endpoints to all clients and let them pick |
| 19:04.31 | JeffM | and have a message to add endpoints |
| 19:04.39 | JeffM | no real "need" for a middle service |
| 19:04.44 | blast007 | the way we have it now is more like classic FPS games. individual dedicated servers running a map. |
| 19:04.55 | JeffM | yeah |
| 19:05.21 | JeffM | I'm a fan of having a single host cluster do N game instances |
| 19:05.25 | JeffM | and redirect as needed on join |
| 19:05.29 | blast007 | then there's a MMO style where you probably distribute stuff across multiple servers and share state. and then the newer competitive FPS games with matchmaking that automatically find players and throw them into an instance. |
| 19:05.42 | JeffM | MMOs don't really work that way |
| 19:05.49 | JeffM | with MMOs there is a gateway cluster |
| 19:05.55 | JeffM | it redirects to internal network servers |
| 19:06.07 | JeffM | and those servers spin up instances as needed |
| 19:06.09 | blast007 | so not shared state? is is sharded for areas? |
| 19:06.14 | JeffM | areas |
| 19:06.16 | blast007 | k |
| 19:06.22 | JeffM | so you are shared with maybe the 100 people around you |
| 19:06.30 | JeffM | and you get shunted as you move |
| 19:06.56 | blast007 | there are some with persistent state |
| 19:06.58 | JeffM | they don't heve a big state with 5000 people in it |
| 19:07.05 | JeffM | sorta |
| 19:07.12 | JeffM | the world has state data that's in a shared database |
| 19:07.22 | JeffM | but most often, high trafic areas are instanced |
| 19:08.16 | blast007 | I forget the name of that space one where people spend thousands of real-world dollars buying ships.. |
| 19:08.24 | JeffM | eve online |
| 19:08.33 | JeffM | that spins up instances for areas |
| 19:08.37 | blast007 | iirc, that one does time stretching during high load |
| 19:08.43 | JeffM | you "warp" from area to area, and that gives them time to shunt them |
| 19:08.45 | JeffM | yes |
| 19:09.00 | JeffM | in that gameplay they actualy have hundreds to thousands of players actualy interacting |
| 19:09.05 | JeffM | so they have to slow it down |
| 19:09.20 | JeffM | most MMOs don't allow that level of massive interaction |
| 19:09.41 | JeffM | like in everquest 1/2, they spin up zones based on load |
| 19:10.05 | blast007 | Guild Wars was kinda "massive-ish" only in the hub towns |
| 19:10.18 | JeffM | when you load to a zone, they try to put you with friends/guildmates, but there are controlls to zone swap |
| 19:10.25 | JeffM | and even those are instanced |
| 19:10.36 | JeffM | there were multiple towns |
| 19:10.49 | JeffM | when you grouped with a friend it'd re-instance you |
| 19:10.58 | JeffM | Destiny does that |
| 19:11.15 | JeffM | maybe 50 people at a time in any single instance. |
| 19:11.42 | JeffM | a 200 v 200 battle in a small space would just not be fun |
| 19:12.23 | JeffM | my favoite large scale game system was subspace. |
| 19:12.32 | JeffM | it did what I think it right for bzflag. |
| 19:13.05 | JeffM | there were a few top level "Servers" |
| 19:13.09 | JeffM | that hosted game rooms |
| 19:13.18 | JeffM | and one room was like the free for all "lobby" |
| 19:13.27 | JeffM | from there you would join or spawn other rooms |
| 19:13.52 | JeffM | most servers forced you to get a specific score in the lobby before you could move to other rooms |
| 19:15.02 | JeffM | each room had at max maybe 200 players |
| 19:15.13 | JeffM | the maps were big, so it wasn't a cluster fuge |
| 19:16.03 | JeffM | the question about if the backend is one or multiple servers is up to the server runners, clients don't care |
| 19:16.13 | JeffM | they were just told "conenct here with this game ID" |
| 19:17.14 | JeffM | but yes, I could probalby build you a server that shared state as an exprirment, once I get the damed map decompressing :) |
| 19:17.23 | JeffM | I think I could do it entirely with a plugin too :) |
| 19:17.37 | blast007 | nah, no need for that |
| 19:18.06 | JeffM | it's API is much more robust |
| 19:28.35 | JeffM | Well |
| 19:29.06 | JeffM | One of my goals was to make a code pass that could do ether combo or split states |
| 19:41.23 | JeffM | 1. Maximize resources for active players |
| 19:41.24 | JeffM | 2. Maintainable code/messages |
| 19:41.24 | JeffM | 3. Disconnect networking from state |
| 19:41.24 | JeffM | 4. Fully integrated API |
| 19:41.34 | JeffM | Those were my goals |
| 20:21.30 | moriah | oh joy....free gay pron: https://forums.bzflag.org/viewtopic.php?f=2&t=19747 |
| 20:22.03 | moriah | lol on his blog name |
| 20:22.26 | moriah | porn* |
| 20:33.54 | *** join/#bzflag catay (~smertens@valyria.catay.be) |
| 20:34.10 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@cpe-172-112-10-183.socal.res.rr.com) |
| 20:34.11 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 20:34.11 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 20:38.02 | *** join/#bzflag FastLizard4 (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 20:48.16 | *** join/#bzflag AAA_awright (~aaa@2607:5300:60:7d4::1) |
| 21:11.10 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 21:11.38 | JeffM | ok, so ZLibStream with a compression level of 9 gives me the same compressed bytestream as the c compress2 :) |
| 21:12.18 | JeffM | 6 bytes diferent than a raw deflate stream |
| 21:14.45 | JeffM | ahh my packing is off by bytes |
| 21:16.26 | blast007 | level 9 is probably overkill |
| 21:16.35 | JeffM | it's an alias for "best" |
| 21:16.40 | blast007 | yeah |
| 21:17.44 | JeffM | ok, got past the decompression stage, now the packed world is just wrong :) |
| 21:17.53 | JeffM | that's much simpler to solve |
| 21:18.34 | blast007 | :) |
| 21:18.57 | JeffM | so I have a license question |
| 21:19.02 | JeffM | all this code is new code |
| 21:19.08 | JeffM | like typed in by hand by me |
| 21:19.22 | JeffM | but I did it while looking at the LGPL bzflag code |
| 21:19.40 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 21:19.43 | JeffM | does that mean my code still has to be LGPL or can I BSD it? |
| 21:20.26 | blast007 | for this, is there an advantage to BSD? |
| 21:20.37 | JeffM | none of my code looks or acts like bzfs code, it just happens to read/write the same binary |
| 21:20.41 | JeffM | I like bzd better |
| 21:20.46 | JeffM | it's presonal prefrence |
| 21:21.09 | JeffM | nobody is going to use it to build a commercial system :) |
| 21:21.11 | blast007 | as for the legal side I things, I'm not sure, but I'd assume you could license it however you want |
| 21:21.20 | JeffM | that's my assumption too |
| 21:21.41 | JeffM | just curious what others opinions were |
| 21:22.41 | JeffM | Happy bunny license it is |
| 21:23.04 | blast007 | you weren't replicating code, but were using the existing to know how to handle the data and flow |
| 21:23.15 | JeffM | yeah I was using it as a data specification |
| 21:26.57 | JeffM | heh ,https://tldrlegal.com/ |
| 21:27.04 | JeffM | I should use the youtube terms of service |
| 21:28.32 | JeffM | apache is probably simplest |