1 /* +------------------------------------+
\r
2 * | Inspire Internet Relay Chat Daemon |
\r
3 * +------------------------------------+
\r
5 * InspIRCd: (C) 2002-2008 InspIRCd Development Team
\r
6 * See: http://www.inspircd.org/wiki/index.php/Credits
\r
8 * This program is free but copyrighted software; see
\r
9 * the file COPYING for details.
\r
11 * ---------------------------------------------------
\r
14 /** Right, Line Buffers. Time for an explanation as to how sendqs work. By the way, ircd people,
\r
15 * before you jump up and down screaming, this is not anything like Adrian Chadd's linebuffer
\r
16 * stuff done for hybrid(and never really completed.) Rather, this is (I think) where linebuffer
\r
17 * was heading, and should have been.
\r
19 * Enough introduction, actual explanation starts here.
\r
20 * In IRCd, we have a sendq. Traditionally, a sendq has been a big string. Stuff is tacked onto
\r
21 * the end, and when we can, we send the user some data off the start of it. A circular buffer.
\r
23 * This model works okay, and is quite simplistic to code, but has a drawback in that most IRC
\r
24 * messages are multicast: topic changes, joins, parts, channel messages, and so on.
\r
25 * This means that for each of these messages, we must do O(n^n) amount of work: bytes ^ recipients
\r
26 * of writes will be made to sendqs, and this is a slow and expensive operation.
\r
28 * The solution comes with the use of this linebuffer class below, which is managed entirely by
\r
29 * the user class (though it *may* be possible to add a server to server implementation of this later,
\r
30 * but that's nowhere near so needed, and nowhere near so trivial, thanks to the inherited nature
\r
31 * of buffered socket, but I digress).
\r
33 * What this class does, in a nutshell:
\r
34 * When we need to send a message to a user, we create a LineBuffer object. It has a reference count, and
\r
35 * we copy the string we need to send into the LineBuffer object also.
\r
36 * We then tack a pointer to this LineBuffer into an std::list stored in the User class.
\r
37 * When the user writes data, a ptr is advanced depending how much of that line they wrote. If they wrote all
\r
38 * of the line, the pointer is popped off the std::list, the ptr is reset, and the buffer's refcount is
\r
39 * decremented - and if it reaches 0, the linebuffer is destroyed as it has fulfilled it's purpose.
\r
41 * Effectively, this means that multicast writes become O(n) + time taken to copy message once, or just about.
\r
43 * We gain efficiency, and much, much better RAM usage.
\r
45 static unsigned int totalbuffers = 0;
\r
51 unsigned long refcount;
\r
53 // Don't let it be copied.
\r
54 LineBuffer(const LineBuffer &) { }
\r
60 printf("Destroying LineBuffer with %u bytes, total buffers is %u\n", msg.length(), totalbuffers);
\r
64 LineBuffer(std::string &m)
\r
66 if (m.length() > MAXBUF - 2) /* MAXBUF has a value of 514, to account for line terminators */
\r
68 // Trim the message to fit, 510 characters max.
\r
69 m = m.substr(0, MAXBUF - 4); // MAXBUF is 514, we need 510.
\r
72 // Add line terminator
\r
79 printf("Creating LineBuffer with %u bytes, total buffers is %u\n", msg.length(), totalbuffers);
\r
82 std::string &GetMessage()
\r
87 unsigned long GetMessageLength()
\r
89 return msg.length();
\r
92 // To be used after creation, when we know how many recipients we actually have.
\r
93 void SetRefcount(unsigned long r)
\r
98 unsigned long DecrementCount()
\r
102 throw "decrementing a refcount when nobody is using it is weird and wrong";
\r
109 // There is no increment method as it isn't really needed.
\r