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