<jilles> you also need to take care of the case where you have servers A, B and C; A can talk to B, B can talk to C but A cannot talk to C
<spb> you haven't thought this through properly, have you
<Diablo-D3> jilles: I already did
<jilles> think cogent vs one of those other bozos
<jilles> level3
<Diablo-D3> jilles: A->C's link fails, A asks B if it can talk to C, it says yes, B relays
<spb> how do you handle servers joining?
<Diablo-D3> spb: in what way?
<Diablo-D3> technically, it just needs to know a list of all servers
<spb> heh
<Diablo-D3> this can be retrieved from, say, other servers
<spb> i'll believe it when i see it
<Diablo-D3> Fine. Pony up hard cash and I'll think about it.
<Diablo-D3> Something like this I'm sure as hell not doing for free.
<spb> bollocks to that
<spb> i'm not the one with the crazy ideas claiming they'll work
<Diablo-D3> No money, no code that apparently even jilles can't write.
<spb> then shut up about it
<Diablo-D3> Hell, my way, it'd be scalable against large servers too.
<nenolod_> ok...
<nenolod_> well, this behaviour is very similar to http://web.archive.org/web/20011221222529/www.dalnet.org/history/money.html
<nenolod_> that guy
* jacob (~jacob@38.112.170.210) has joined #staticbox
<jacob> spb: hey, ltns.
<nenolod_> Diablo-D3, well, consider this
<nenolod_> Diablo-D3, if you write a mega superscalable irc server with redundancy
<nenolod_> Diablo-D3, don't you think you could like, sell it to people?
<nenolod_> and thus recomp yourself?
<Diablo-D3> why would I want to when I can just GPL it instead?
<nenolod_> Diablo-D3, because you just said you would require money to make it a worthwhile venture
<spb> jacob: hi
<Diablo-D3> nenolod_: I would require money to dedicate my time completely to it.
<nenolod_> Diablo-D3, well, you claim to be dedicated to this network, so shouldn't you at least spend some of your time pursuing this project you propose?
<jacob> that's the beauty of open source, every little bit counts.
<Diablo-D3> nenolod_: No, you want something that apparently none of you know how to code
<Diablo-D3> I dont even get why you think its so hard
<nenolod_> Diablo-D3, because irc state is distributed
<jacob> Diablo-D3: or you don't, and have no idea the intricacies involved.
* batmannu has quit (Ping timeout: 246 seconds)
<Diablo-D3> I've been designing a scalable network message passing system in my head for about two years now
<Diablo-D3> IRC has been going about it the wrong way since it's inception.
<nenolod_> Diablo-D3, this isn't just about messages
<spb> then do it right
<spb> prove us all wrong
<nenolod_> Diablo-D3, there's also transactions and state that have to be the same on every server
<nenolod_> or people can abuse to desync the network
<nenolod_> infact, services works on this principle
<nenolod_> by using various messages to alter the network state
<Diablo-D3> Yes, but this is why timestamps exist
<Diablo-D3> and I dont mean the faggoity ones IRC servers use
<jacob> not to mention simple message tracking that doesn't need to exist in a hub/leaf topology but does in a mesh/ring, to see which messages have been echo'd to which servers
<nenolod_> Diablo-D3, so how do you handle situations where TS is off on a server?
<jacob> it would be horrid on ram usage trying to keep track of md5sums or whatever of each message sent for the past 30ish seconds
<Diablo-D3> nenolod_: the server will be dropped.
<Diablo-D3> And then repeatedly dropped until someone fixes the time on it.
<nenolod_> Diablo-D3, ok, good
<nenolod_> Diablo-D3, now consider that that server has 600 users on it
<jacob> Diablo-D3: so you're going to use a different time_t than charybdis does?
<Diablo-D3> nenolod_: the server wont xcept users.
<nenolod_> Diablo-D3, which can't access the network resources
<Diablo-D3> er, accept
<nenolod_> Diablo-D3, that's fascinating. how do you intend to determine whether or not it should accept users? what about the users already on the server?
<Diablo-D3> Users already on the server are kicked for safety reasons
<jilles> that's not nice
<nenolod_> man, that brings a whole new meaning to "thanks for flying $network"
<Diablo-D3> No, but it works.
<spb> that's possibly the stupidest idea you've had yet
<jacob> and how is it going to determine whether its TS is off if it's not connected to the network to know?
<nenolod_> jacob, well, it connects, get an SVINFO, and then panics
<nenolod_> but then
<spb> what if two servers that weren't previously linked to anything link together and find their clocks are out?
<nenolod_> rats, spb got to it first
<spb> do they both kick off all their users while refusing to link?
<jacob> fuck users, our timestamps are moer important!
<nenolod_> needs moar TS
<Diablo-D3> you're assuming that the time difference is enough
<Diablo-D3> I'm allowing a fair amount of time difference
<jacob> even being off by 1 can cause massive desyncs
<jacob> i sitll wanna know where you're pulling time
<Diablo-D3> Im not sure what you're missing neno
<spb> in your new scheme, you're far more sensitive to tiny differences
<Diablo-D3> Do servers not sanity check results?
<nenolod_> well, in charybdis, there's two rings of trust
<Diablo-D3> Because if they don't, thats why IRC is fucked up
<nenolod_> the first ring, which is all of the servers
<nenolod_> and then the second ring, which is u:lines
<Diablo-D3> shuddup neno, for a sec
<Diablo-D3> <Server 1> User did a chanop power
<Diablo-D3> <Server 2> To me, User isnt a chanop, is he?
<Diablo-D3> <Server 1> Yes
<nenolod_> Diablo-D3, it doesn't work that way
<Diablo-D3> <Server 2> Fix, perform chanop power
<nenolod_> Diablo-D3, IRC state is distributed. there is no querying across servers.
<jilles> charybdis does not check if a remote user has ops, only that they are not abusing split
<nenolod_> it's like a DHT
<Diablo-D3> nenolod_: exactly
<Diablo-D3> which is why its broken
<nenolod_> how the hell is it broken?
<Diablo-D3> its not trying to replicate state
<jilles> querying all that stuff would be *slow*
<jacob> and you want to waste how much bandwidth?
<jilles> every time a user joins you need to send the userlist
<Diablo-D3> not really, I can perform queries in parallel
<Diablo-D3> jilles: yes, and the userlist is sent as the server knows it
<nenolod_> Diablo-D3, this protocol of yours is growing more complex by the second
<Diablo-D3> if you were attached to that server, you'd see a fixme of "server has opped User"
<jacob> i'll stick with TS5/TS6 thanks :x
<spb> more complex, slower, and more wasteful of bandwidth
<spb> if we wanted it to take five minutes for everyone to read our comments, we'd use mass email
<Diablo-D3> the query is /only/ done if something is wrong
<nenolod_> how do you determine if something is wrong then?
<Diablo-D3> the above example is one
<nenolod_> i'm not asking for examples, i'm asking for criteria
<Diablo-D3> A message was sent to do something that can't happen
<nenolod_> and we've gotten off course
<nenolod_> how do you intend to do mesh linking
<Diablo-D3> neno, have you been eating paint chips again?
<nenolod_> it's a valid question
<Diablo-D3> no its not
<Diablo-D3> you open multiple sockets simutaniously
<nenolod_> how do you know which server got which message, and that they got it in the right order?
<Diablo-D3> you actually don't need to baby sit the right order on machine scales
<Diablo-D3> you only need to baby sit the right order on human scales
<nenolod_> no, because irc communication would have to be asynchronous for meshing to work right
<nenolod_> it can't "block" i/o
<Diablo-D3> Yes, and it would be asynchronus
<Diablo-D3> messages sent at the exact same time on two different servers would appear to be out of order
<nenolod_> if it is asynchronous, and not all links are up, then messages can be sent in the wrong order
<jilles> and order may matter
<Diablo-D3> nenolod_: in what way?
* Stskeeps (~stskeeps@84.238.11.65bdb34c) has joined #staticbox
<jilles> all messages from one source to one channel or user must not be reordered
<Diablo-D3> jilles: partially correct
<nenolod_> Diablo-D3, why do you say partially?
<Diablo-D3> all messages from one user to any user/channel must be babysat if out of order
<nenolod_> yes, and how do you intend to do that?
<nenolod_> and, more specifically, how do you intend to check to see if it's out of order?
<Diablo-D3> timestamps.
<jilles> needs more than second accuracy
<Diablo-D3> yes, it will use subsecond accuracy
<nenolod_> well, not just that
<nenolod_> what about conditions where one clock is off by x amount of nanoseconds?
<Diablo-D3> wont matter
<nenolod_> thus causing duplicate TS messages
<Diablo-D3> subsecond accuracy will only be used in relative to other messages
<nenolod_> well, wouldn't you want to use something more along the lines of a non-random message ID?
<nenolod_> probably using some sort of hash of the server's identity as a toasting value
<Diablo-D3> yes, but only if I can say "this message is followed by this ID"
<nenolod_> why wouldn't you put it at the top of the packet?
<nenolod_> e.g.
<nenolod_> typedef struct ircpacket_ {
<Diablo-D3> no, Im saying, messages would have to know the name of the next message
<nenolod_> char *id;
<nenolod_> char *msg;
<nenolod_> } ircpacket_t;
<nenolod_> + whatever else crap in the packet
<nenolod_> well
<nenolod_> the problem with that is that
<nenolod_> what if there is no next message?
<nenolod_> ;p
<Diablo-D3> the next message would be a null message.
<nenolod_> but, if there is no next message, you would have to wait X amount of time to time out
<nenolod_> IRC is a state machine, you can't do that
<Diablo-D3> I can do that, actually.
<nenolod_> what? you're going to write a time machine in C?
<Diablo-D3> I already know there is no next message in my queue
<nenolod_> so you do it when you flush sendq?
<Diablo-D3> no, I do it as the last step
<Diablo-D3> most messages will most likely have a null message ID as the next message
<Diablo-D3> (I technically dont even have to send the null message)
<nenolod_> ok, so you would have over the wire
<Diablo-D3> messages from /one source/ have to be in order
<nenolod_> message 1: <irc packet magic code><message id><message>
<nenolod_> er
<nenolod_> message 1: <irc packet magic code><message id><message><next message>
<Diablo-D3> messages from /multiple sources/ dont have to be in order of each other
<nenolod_> message 2: <irc packet magic code><message id><message><zero>
<nenolod_> right?
<Diablo-D3> nenolod_: maybe, but probably no
<nenolod_> ok, just confirming
<Diablo-D3> message 1: <message id><next message id of, say, 0><message>
<Diablo-D3> there cannot be two messages with next message id of 0 in the queue from the same user
<nenolod_> ok
<Diablo-D3> and messages still cary a second-accuracy TS
<nenolod_> i thought it was subsecond
<nenolod_> as in struct timeval?
<Diablo-D3> subsecond accuracy is encoded into the message id
* batmannu (~batmannu@ecaa.baltcom.ee) has joined #staticbox
<Diablo-D3> each new second causes a new set of joined messages
<Diablo-D3> and an entire set has to be received and spat out before it will process the next
<nenolod_> that's a lot of arbitrary rules
<Diablo-D3> not really
<Diablo-D3> its simple safety checking that ircds should already be doing
<nenolod_> ircds dont have to do such checks because they aren't meshed...
<Diablo-D3> exactly
<jacob> Diablo, i want to understand. are you're doing this realtime or event driven?
<Diablo-D3> jacob: both
<Diablo-D3> jacob: epoll works wonders.
<jacob> ok.
<nenolod_> what the hell does epoll have to do with this
<jacob> i can't wait to see it
<Diablo-D3> nenolod_: easy, irc is event driven
<Diablo-D3> but I don't have to do 'real' polling and fag up the design
<nenolod_> ok, but, epoll is an I/O mechanism
<nenolod_> well
<Diablo-D3> my way, I just wait for packets, and do stuff based on the state of ongoing tasks
<nenolod_> irc.sacredspiral.co.uk runs Debian/kFreeBSD
<nenolod_> which does not have epoll
<Diablo-D3> yes, and its going to suck for bsd users
<jacob> nenolod_: THEN MAKE THEM UPGRADE
<jacob> lulz
<Diablo-D3> because anything that doesnt use epoll runs like shit
<nenolod_> i'm 99.9% that some other servers around here run BSD
<jilles> kqueue works great for IRC servers
<jacob> FreeBSD wraith.sorcery.net 6.1-SECURITY FreeBSD 6.1-SECURITY #0: Mon Dec 4 07:53:55 UTC 2006 root@builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
<jacob> irc server, freebsd.
<jacob> :P
<jacob> but i think freebsd has epoll
<nenolod_> Diablo-D3, no
<nenolod_> er
<Diablo-D3> jacob: it probably doesnt
<nenolod_> no it has kqueue
<Diablo-D3> kqueue probably can be leveraged the same way
<Diablo-D3> anyhow, neno, the reason messages from the same user can get out of order is because of pasting large amounts of text
<nenolod_> yeah. packet loss has nothing to do with it.
<nenolod_> Diablo-D3, well you should wiki this up
<nenolod_> define it as a "spec" for staticbox to implement by X amount of months
<Diablo-D3> I dont wiki shit
<Diablo-D3> and Im going to bed, because I have to be up in 8 hours
<Diablo-D3> night
* Diablo-D3 has quit (Quit: This computer has gone to sleep)
* muriani (~james@38.112.170.210) has joined #staticbox
<jacob> ...
<muriani> ...?
<jacob> muriani: you missed the bst line he pasted
<jacob> er, said
<jacob> 11:01 <@Diablo-D3> and Im going to bed, because I have to be up in 8 hours
<jacob> :
<jacob> :P even
<muriani> hey, I do that
<muriani> or try to, at least
<muriani> bed at midnight, alarm at 8am.
<jacob> ... you don't announce "omg i'm not gonna get enough sleep, only got 10 hours till i gotta be up"
<muriani> naw, I just go *poof*
<jacob> that's the kind of statement you make at 5-6 hours, not 8 ;p
<muriani> right
<muriani> "dood, I gotta be up in 30 minutes... bedtime"
<jacob> right
<muriani> ..I
<muriani> I've pulled that shit before
<jacob> "dude, just stay up, go take a hot shower and spank it"
<jacob> ;p
<muriani> fuckig never again
<muriani> alright then guys, I'm gonna work now
<muriani> got an ircd to write in php
<muriani> *poof*
* muriani has quit (Quit: I SAID *POOF*)
<jacob> haha
* jacob has quit (Quit: leaving)