01:01 < eeeee> deen: how much memory can you spare for websockets implementation? 01:02 <@deen> eeeee: how much do we need?! 01:02 <@deen> as little as possible, as much as necessary 01:03 < eeeee> i'm trying to figure out what would be a good tradeoff for the buffer size 01:03 <@deen> what buffer? 01:03 <@deen> is it for each player? 01:03 < eeeee> libwebsockets is async so have to add some buffers to hack it into teeworlds polling model 01:03 < eeeee> for each player slot, yeah 01:04 <@deen> how much would be reasonable? 01:04 < eeeee> more accurately, a receive buffer for each player slot and one shared send buffer 01:05 < eeeee> er no the other way around 01:05 < eeeee> oh i guess if we force websockets clients to do http map download then we can get away with a small buffer 01:06 < eeeee> will do that 01:07 <@deen> ok, great 03:01 < eeeee> did you revert/disable fast download? 03:01 < eeeee> i'm trying to connect to a server but it keeps changing maps before i can finish downloading :D 03:09 <@deen> hm? 03:09 <@deen> with new ddnet client? 03:09 <@deen> is that by chance a server running an old ddnet server version? 03:10 < eeeee> new ddnet client compiled to js :/ 03:10 <@deen> what server are you connecting to? 03:10 < eeeee> some ddnet server 03:10 <@deen> regular ddnet one, online? 03:10 < eeeee> yeah 03:10 <@deen> didn't change anything there 03:10 < eeeee> hmm 03:10 <@deen> (I hope) 03:11 <@deen> works from regular client 03:11 < eeeee> oh nvm. it works now after i restarted the proxy 03:11 <@deen> good 03:11 < eeeee> node.js :( 03:12 < eeeee> pullreq for websockets is almost ready 03:12 < eeeee> have to think what to do with the client 03:13 < eeeee> currently websockets are included from system.h so client would also be built with them (that is if you ./bam config websockets=1 ) 03:14 < eeeee> they are not included by default tho so maybe we can just hope nobody does that 04:22 <@deen> of course nobody would do that, it's fine 10:02 < Nimda> DDNet USA went down! 10:03 < Nimda> DDNet USA went back online! 10:19 <@EastByte> http://eastbit.net/priv/showcolbot.webm 10:19 <@EastByte> this should be easy to detect, even clientside 11:07 < ddnet-commits> [ddnet] def- pushed 3 new commits to DDRace64: http://git.io/bQJH 11:07 < ddnet-commits> ddnet/DDRace64 142c386 Learath Lea: Remove obsolete function prototype. 11:07 < ddnet-commits> ddnet/DDRace64 ec84bb8 Learath Lea: Actually use the storagetype we passed. 11:07 < ddnet-commits> ddnet/DDRace64 ec8a4b0 Dennis Felsing: Merge pull request #143 from Learath2/pr_cleanup... 11:25 < Nimda> Don't Panic by MarvinProductions just released on Brutal at 2015-02-08 11:24 12:01 <@deen> Welcome, cris272 12:01 < cris272> hello deen 12:06 <@deen> how are you? 12:16 < cris272> fine fine and you ? :) 12:17 < cris272> http download look nice 12:17 < cris272> i have't the time to have how fast i downloaded the map 12:17 < cris272> i have't the time to watch how fast i downloaded the map 12:20 <@EastByte> deen: how did you strip linux binaries? 12:21 <@heinrich5991> strip 12:21 <@EastByte> ah 12:21 <@heinrich5991> :) 12:43 <@deen> I'm fine too (and was afk) 19:09 < Nimda> DDNet South Africa went down! 19:10 < Nimda> DDNet South Africa went back online! 21:17 <@EastByte> I don't like the way http map downloads currently work 21:18 < Learath2> EastByte: elaborate 21:18 <@heinrich5991> why? 21:18 <@heinrich5991> (@EastByte) 21:18 < ddnet-commits> [ddnet] def- pushed 1 new commit to DDRace64: http://git.io/bdIG 21:18 < ddnet-commits> ddnet/DDRace64 dd3fae0 def: Cleanup 21:19 <@EastByte> the it works right now, it should be atleast limited to ddnet servers 21:19 <@EastByte> ever map no matter which mod is requested from deen's srv now 21:20 <@EastByte> every* 21:20 < Learath2> oh yeah i told deen he could do that 21:20 <@deen> or we turn it into a proper map database with heinrich5991's database 21:20 <@heinrich5991> deen: if you have the bandwidth? 21:21 <@deen> i guess i do 21:21 <@EastByte> the proper solution in my opinion would be that the server tells the client whether and where to dl maps from 21:21 <@EastByte> so it's independent from ddnet 21:21 <@EastByte> and a benefit for all 21:21 < Learath2> client.cpp:L1555 adding a && gamemode == ddne) there should fix it 21:22 <@deen> great, then i need to wait 10 minutes to download map on chilean vanilla server again =/ 21:22 < Learath2> well then you need to add all them maps to the server 21:23 <@EastByte> deen: you're funny 21:23 <@deen> i did, all maps on ddnet's servers should go over http 21:23 <@deen> EastByte: why? 21:24 <@EastByte> you wouldn't play on chilean servers with a >200 ping 21:24 <@EastByte> well you would of course 21:24 <@deen> so I shouldn't connect to my own servers? 21:24 <@deen> and i quite often play with ping > 200 21:25 <@EastByte> if it's only for you, use your own branch :P 21:25 <@deen> you think i'm the only one who doesn't like that TW downloads maps slowly? 21:27 <@EastByte> it wouldn't be slowly if the hoster itself could provide http dl 21:27 <@EastByte> slow* 21:28 <@heinrich5991> you could provide both solutions I guess 21:28 <@heinrich5991> if the server advertises a HTTP, download from there, if not, try DDNet's server, otherwise use teeworlds' map download 21:29 <@EastByte> what would be the benefit? 21:30 <@heinrich5991> fast downloads everywhere, not only where the hoster explicitely opted in 21:31 <@heinrich5991> always assume that the default settings were used in software 21:31 <@heinrich5991> because that's how it should work and how it works 21:31 <@EastByte> but still all map requests would cause an http request 21:31 <@heinrich5991> what's wrong with that? 21:32 <@EastByte> lets say deen's server is unavailable because of ddos attacks 21:32 <@EastByte> then all map requests would slow down 21:32 <@EastByte> (takes time to fall back to tw map dl) 21:32 <@heinrich5991> then maybe that problem should be tackled instead? 21:32 <@EastByte> well, how? 21:33 <@heinrich5991> aggressive timeout on the HTTP server e.g. 21:33 <@EastByte> limit dl time to one second? 21:34 <@EastByte> I really don't like that 21:35 <@heinrich5991> why? 21:38 <@EastByte> it reminds me of proprietary/company like behavior trying to track all clients by leading there requests to their own server 21:38 < Learath2> a good timeout should fix the situation 21:40 < Learath2> EastByte: well give me a solid way to do this and ill fix it 21:40 < Learath2> we have no way of knowing if deens server is under attack 21:41 <@EastByte> a timeout would be the only solution for that problem 21:45 <@EastByte> anyway if it should stay like this, I still have some suggestions 21:46 <@EastByte> http dl should probably be disabled in lan and for maps of really small size 21:46 < Learath2> yeah i couldnt determine if fastdl is faster then http for small maps 21:47 <@EastByte> all the data transfered by tcp might be bigger then a small map itself 21:47 <@EastByte> I'm talking about http/tcp headers 21:47 <@EastByte> well exaggerated anyway 21:49 <@EastByte> also establishing the connection would take too much not worthy time 21:49 <@heinrich5991> tcp header is 40bytes 21:49 < Learath2> i do like the idea of letting the server send a http adrress 21:49 <@EastByte> heinrich5991: so how many tcp headers are transfered? :D 21:49 <@EastByte> atleast 8 I guess 21:49 <@heinrich5991> so that's 320 bytes 21:50 <@EastByte> + http header 21:50 <@heinrich5991> small maps are a few kilobytes 21:51 <@heinrich5991> you need SYN, SYN+ACK, ACK, HTTP GET, HTTP response 21:51 <@heinrich5991> (and as an additional bonus, you can use cloudflare) 21:53 <@EastByte> ctf5 for example is 12K 21:53 <@heinrich5991> and that's only using standard tilesets 21:54 < Learath2> could give it a actual test 21:54 <@EastByte> I think http becomes reasonable from ~50K 21:54 <@EastByte> establishing the connection can take over a second 21:55 <@heinrich5991> where do you get that data? 21:55 <@heinrich5991> should be double RTT 21:55 <@EastByte> sorry, based on my experience 21:55 <@heinrich5991> experience where? from browsers? 21:56 <@EastByte> no, I often noticed that establishing tcp the first for example takes longer 21:58 <@EastByte> maybe some nods slow syn/ack packets down 21:58 <@EastByte> nodes* 21:58 <@EastByte> or firewalls 22:10 <@EastByte> hm looks like that's not the case