1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices] cheers. ideas.
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20cheers.%20ideas.&In-Reply-To=E13jVsB-000CAP-00%40manx.dreamhaven.net">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"000847.html">
11 <LINK REL=
"Next" HREF=
"000849.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices] cheers. ideas.
</H1>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20cheers.%20ideas.&In-Reply-To=E13jVsB-000CAP-00%40manx.dreamhaven.net"
17 TITLE=
"[IRCServices] cheers. ideas.">anarki at flamebait.org
19 <I>Wed Oct
11 18:
07:
07 PDT
2000</I>
21 <LI>Previous message:
<A HREF=
"000847.html">[IRCServices] cheers. ideas.
23 <LI>Next message:
<A HREF=
"000849.html">[IRCServices] Scalability
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#848">[ date ]
</a>
27 <a href=
"thread.html#848">[ thread ]
</a>
28 <a href=
"subject.html#848">[ subject ]
</a>
29 <a href=
"author.html#848">[ author ]
</a>
34 <PRE>ok, ignorant question follows:
37 What makes DALnet services work well with it's database(s)?
60K users,
100k
38 registered nicks easily.
40 DALnet has splits just like all other large nets, granted, but it is
41 usually an IRCd that splits, and not services. Services of course still has
42 it's downtime, but as a general rule they are up.
46 At
04:
10 PM
10/
11/
2000 -
0700, you wrote:
47 ><i> Okay, my two cents:
49 </I>><i> I'll be the first to admit that the current Services database format
50 </I>><i>is less than ideal. When I originally designed Services, I designed it
51 </I>><i>the network I had started a bit earlier, which at the time had at most
52 </I>><i>20-
30 simultaneous users. Services can write a database of a few thousand
53 </I>><i>nicks quickly enough not to matter, but up that by an order of magnitude
54 </I>><i>and you'll start seeing lag just from writing the database. Moreover, a
55 </I>><i>single bit error in the wrong place and you lose the entire database (and
56 </I>><i>apologies to anyone who's experienced this).
58 </I>><i> There's also the issue of accessing, and particularly altering, the
59 </I>><i>databases from outside of Services. Although access alone isn't really a
60 </I>><i>problem--if you want to access the Services databases now, you can do it
61 </I>><i>by borrowing the database loading code; listchans and listnicks work like
62 </I>><i>that--altering the databases from outside of Services' control brings in
63 </I>><i>all the classic problems of multithreaded applications--races, deadlocks,
64 </I>><i>that sort of stuff. Which isn't to say it can't be done, of course, but
65 </I>><i>as Andrew Kempe commented, it'll take a good deal of work. My personal
66 </I>><i>thought is that it would be better done as a multi-step process: first
67 </I>><i>implement some manner of sending Services certain commands from outside
68 </I>><i>(e.g. register/drop a nick), iron out the problems there, then look at
69 </I>><i>going to complete external read/write support.
71 </I>><i> As far as database format goes, I personally don't like either the
72 </I>><i>XML or SQL options which have been presented so far. While I agree that
73 </I>><i>XML would make external viewing/editing of the databases easier and reduce
74 </I>><i>the possibility of single-bit crashes, it would place even more strain on
75 </I>><i>Services when updating the databases--not only do you have to write all
76 </I>><i>the data to disk each time, you have to convert it all to ASCII and you
77 </I>><i>have to add all sorts of formatting stuff, meaning both more CPU time and
78 </I>><i>more disk space needed (I could easily see the database size tripling or
79 </I>><i>worse). As far as SQL goes, relying on an external program to be running
80 </I>><i>in order to write data is just ugly; besides which, the delay in sending
81 </I>><i>commands to the SQL server to read/write data would almost certainly be
82 </I>><i>untenable. (A
30-millisecond delay on an update request, for example, is
83 </I>><i>fine if the requests are spread out among lots of clients; it's not fine
84 </I>><i>if you have one program trying to do
50 updates a second.) Besides which,
85 </I>><i>there are probably a lot of people, myself included, who wouldn't want to
86 </I>><i>use Services if it required installing an SQL server as well.
88 </I>><i> I personally see no reason why a proprietary format wouldn't work
89 </I>><i>fine, as long as a library or some such was provided to allow other
90 </I>><i>programs to access it. In fact, given that the most important thing for
91 </I>><i>Services is to be able to respond quickly to user requests, I think this
92 </I>><i>is the best solution. There really aren't any similar systems you can
93 </I>><i>compare Services to (at least, none come to mind); if you want to talk
94 </I>><i>about SQL, I would almost expect Services to act as an SQL _server_, not
97 </I>><i> Actually, something like that may end up being a good solution after
98 </I>><i>all. There's no reason why external programs have to access the data
99 </I>><i>_files_ for Services, just like database clients typically don't directly
100 </I>><i>access the database server's data files; you can just have Services
101 </I>><i>respond to requests through some channel--e.g. a control socket--and
102 </I>><i>allow data access through that channel, like a database server. The only
103 </I>><i>need to access the files directly would be if they got corrupted, and
104 </I>><i>with a good file structure design such occurrences (and the damage they
105 </I>><i>caused) could be reduced to almost nil.
107 </I>><i> Comments?
109 </I>><i> --Andrew Church
110 </I>><i> <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at dragonfire.net
</A>
111 </I>><i> <A HREF=
"http://achurch.dragonfire.net/">http://achurch.dragonfire.net/
</A>
113 </I>><i>---------------------------------------------------------------
114 </I>><i>To unsubscribe, send email to
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org
</A>
115 </I>><i>with
"unsubscribe ircservices
" in the body, without the quotes.
118 ---------------------------------------------------------------
119 To unsubscribe, send email to
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">majordomo at ender.shadowfire.org
</A>
120 with
"unsubscribe ircservices
" in the body, without the quotes.
129 <LI>Previous message:
<A HREF=
"000847.html">[IRCServices] cheers. ideas.
131 <LI>Next message:
<A HREF=
"000849.html">[IRCServices] Scalability
133 <LI> <B>Messages sorted by:
</B>
134 <a href=
"date.html#848">[ date ]
</a>
135 <a href=
"thread.html#848">[ thread ]
</a>
136 <a href=
"subject.html#848">[ subject ]
</a>
137 <a href=
"author.html#848">[ author ]
</a>
projects / irc.git / blob