| |
| |
| |
|
Page: 1 2
<AndroSyn> 68 on igs..
<anfl> [22:03] --- ATABLE: 66.6.219.*
<anfl> [22:03] --- ATABLE: 151.100.77.*
<anfl> [22:03] --- ATABLE: 66.132.201.*
<anfl> [22:03] --- ATABLE: 66.90.76.*
<anfl> [22:03] --- ATABLE: 209.142.203.*
<anfl> ah.
<AndroSyn> i converted all of those ages ago :P
<AndroSyn> and threatened to beat people unless they used cidr :P
<AndroSyn> i seem to remember writing code ages ago to convert those to cidr klines
<AndroSyn> must be we ripped it out or something
<AndroSyn> when i say ages i mean..pre-forking timespan..
<AndroSyn> unless i never committed it..
<AndroSyn> heh
<anfl> most of these are choopamon
<AndroSyn> oh i screamed about that too ages ago
<AndroSyn> we don't have an oomon anymore though
<AndroSyn> didn't need it
<anfl> yeah, im not sure why we still do
<anfl> but we should add some code to automagically convert cl*** b/c into cidr
<AndroSyn> yeah thats trivial
<anfl> maybe just in kline, and convert before we do anything with it
<anfl> though I suppose it cant hurt in add_conf_by_address()
<AndroSyn> just as long as we don't do it for glines
<AndroSyn> we're fine
<anfl> hmm
<anfl> im just thinking about it
<AndroSyn> don't you wanna put glines in a big linked list? :P
<anfl> we can convert them
<anfl> we just cant do it before we send them out
<anfl> actually
<anfl> this would possibly create a problem for lookups
<gp_> Bye.
<anfl> because we'd have to do a conversion on specific finds for an unkline etc
<anfl> so maybe just /kline is better ;-)
<AndroSyn> that was my point ;)
<anfl> ok, heres what I think we'll do
<anfl> you do that conversion in mo_kline(), convert it before we apply the kline and change the entire host
<anfl> ill port the dline patricia over
<anfl> then ill add hostmask hash statistics into stats B
<anfl> and then we'll run some kline files through it and see what we need to do? :)
<anfl> thatll also give us a good judge of how big the hostmask hash needs to be :)
<anfl> as we could decide we should add another patricia for ip based klines
<AndroSyn> those could in theory go in with dlines
<AndroSyn> but probably wouldn't be worth it
<anfl> for the overhead of a patricia tree, no ;-)
<anfl> ill grab a list of all the tklines on every efnet server tomorrow
<anfl> thatll show whether its worth having a patricia for them
<anfl> hell
<anfl> id possibly be inclined to split the hostmask hash in two
<anfl> but its probably not worth it ;-)
<AndroSyn> comm_checktimeouts() is horrible..
<anfl> actually thinking about it
<anfl> moving ip based stuff into a patricia is gunna save us ram anyway
<anfl> maybe
<anfl> not sure what overhead is of a node in patricia compared to addressrec
<AndroSyn> 1.06 seconds/call for comm_checktimeouts()
<AndroSyn> that's just not nice..
<anfl> ew
<AndroSyn> not really sure what to do about that though..
<AndroSyn> other than doing X number of checks per call
<AndroSyn> and then picking up where we left off next call
<AndroSyn> doesn't solve the problem, just spreads it out a bit
<AndroSyn> you know...
<anfl> [15] 9.6 59.11 28.01 1592467 find_conf_by_address [15]
<anfl> 26.23 0.00 936314680/937478651 match [37]
<anfl> heh
<anfl> nice :)
<AndroSyn> i think the only thing that uses the timeout stuff..
<AndroSyn> are outbound tcp connections..
<AndroSyn> i think we'd be better off making a list of fds that want timeout handling..
<anfl> what about flood_recalc()?
<AndroSyn> i rewrote that in devel
<anfl> ah :)
<AndroSyn> it just loops over the lclient_list now
<AndroSyn> which makes a lot more sense
<AndroSyn> really the only major user of the timeout stuff is the identd checking
<AndroSyn> outbound server connections use it as well..but that is trivial..
<AndroSyn> but i'm outta here..
<AndroSyn> bbl
<anfl> later :)
<anjuta> is somebody by chance aware of hybserv's code ?
<AndroSyn> aware of it how?
<anjuta> i'm trying to understand the meaning of one constant, commented as "size of chanserv hash table", which is just 256..
<anjuta> it seems a bit too low for me, but i could be wrong..
<jilles> hmm
<jilles> be somewhat more concrete
<anjuta> /* hash table of registered channels */ struct ChanInfo *chanlist[CHANLIST_MAX];
<AndroSyn> if CHANLIST_MAX is only 256...
<AndroSyn> yeah that would be a touch on the small side..
<anjuta> CHANLIST_MAX is just 256.. should this imply there is an ***umption of only 256 registered channels or i'm funny wrong ?
<AndroSyn> well..its small, but not for the reasons you think its small :P
<AndroSyn> 256 is terribly small for a hash table
<jilles> the hybserv derivative I have here has 16384 for CHANLIST_MAX
<anjuta> well, i have some 20K (?) registered channels on my network.. should I increase this size ? :)
<anjuta> i'm temporary debugging the hybserv, before the replacement is finished :/
<AndroSyn> who changed it to 256?
<anfl> heh, these hybrid coders are funny :p
<anjuta> i suppose it has always been 256 :)
<AndroSyn> heh
<jilles> there doesn't seem to be any code for "small network"
<anfl> there doesnt need to be
<anfl> the only thing small network does is reduce the memory footprint :)
<jilles> anfl, well this wasn't about ratbox
<anfl> ah :)
<jilles> this was about a hybserv derivative
<anfl> eww
<anfl> deriving something from hybserv
<anfl> :p
<jilles> yeah eww
<anfl> inconsistent coding styles, inconsistent approaches to solving problems
<anfl> no long term direction
<anfl> the latter is the most important by far :)
<jilles> I don't think this fork has incorporated any code from the trunk since it was forked a few years ago
<anfl> andro: hybrid is getting quite lost without diane there to explain why you dont just change the WATCH protocol
<anfl> (etc)
<jilles> diane has left there?
<anfl> no, but she doesnt provide authority and direction anymore
<anjuta> anfl, true
<AndroSyn> yeah i see that..i just sent a little reply explaining why its bad :P
<anfl> like they removed the scache
<AndroSyn> i remember having the discussion with diane many years ago about why its there
<anjuta> umm, jilles, the current hybserv has the same constant.. /me is getting confused
<anfl> andro: aye
<anfl> its something that looks like bloat
<AndroSyn> and looks like a huge memory leak, but isn't ;)
<jilles> scache is even better without a char name[64] in struct Client ;-)
<AndroSyn> indeed
<anfl> sometimes deliberately coding memory leaks is useful :)
<anfl> I did them for hooks
<AndroSyn> with the scache stuff, its like, how many server names are you gonna see in the period of say a year on a network..
<anfl> same with hooks
<AndroSyn> if you had 255 servernames, you'd end up using 16k or so of memory..
<AndroSyn> which ain't gonna break the bank
<jilles> a potential issue is damaged TS5 NICK commands
<jilles> depending on whether you find_or_add() right away or first check it exists
<anfl> check first of course :)
<myfualt> hi all can any one help me out
<anfl> not unless you ask a question.
<AndroSyn> on irc, its always better to ask the question and not ask to ask a question
<myfualt> :>
<AndroSyn> by doing that you already asked a question, thus you didn't ask to ask a question anyways because you asked a question asking if you could ask a question
<myfualt> hahahahahahhah i heard about IRCd and i want to know what does it mean can you helmp me?
<AndroSyn> what your irc client is connected to right now
<AndroSyn> is an ircd
<myfualt> can you tell me what does it mean i mean "DNS" --> domain name server
<myfualt> so ircd is --->
<anfl> irc daemon?
<myfualt> so ircd is aprogram is installed in the hosting computer and its providing for irc chat?
Return to ratbox
or
Go to some related
logs:
football
politics
|
|