[IRCServices] New services implementations & Updates?
Chris Knipe
cgknipe at mweb.co.za
Sat May 27 09:53:20 PDT 2000
Mwhello all :)
Memo: IRC Services - New Implementations.
-----------------------------------------
Introduction:
~~~~~~~~~~~~~
The IRC Services as we know it improved dramaticaly over the last few
months.
We have this greatly to thank to Andy Church, Adrew Kempe, and this
mailing
list with all the users and their suggestions about the services.
Many thanks to everyone who has kept these services alive and in
development.
It's truly becoming the key software package on tons of networks out there
today :)
This memo deals with the implementation of three new key code updates to
the
services structure as they are today. All three of the implementations
will
require drastic coding to the services, but all three of them are also
quite
important factors in the long run of the irc services. Because of the
seriousness of these implementations, I have decided to discuss this in an
draft memo.
The new implementations will cover: MultiCast Networking Support (This
*should*
be cross-coded into IRCD's aswell), IPv6 Support (For future usage), and
lastly
SQL DataBase Support.
1. MultiCast Networking for IRC Networks & Services:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A while ago, when Andy handed services development over to Andew, Andy
mentioned that he was working on drafts for an new IRC Internet
Standard. It
never really concirned me that much, seeing that I wasn't that much into
the
development side of things. Lately, this scenario changed quite a bit,
and
networking, communication, and development became my life.
Multicast networking is mostly used in high-traffic scenarios. Commonly
seen
in applications which make use of audio and video broadcasting over the
Internet (Real Audio / Video & Microsoft's NetShow Services). Recently,
proxy servers also began utilizing this type of networking to reduce load
on
networks between peer'ed proxy servers with much success.
Multicast networking makes use of Class D IP addresses, namely, 224.0.0.0
with
an subnet of 240.0.0.0. The key advantage over TCP networks, is that TCP
utilize an unicast networking scheme, connecting point A to point B and
setting up an datastream between these two points. Because of the fact
that
this datastream can be quite insuficient (perhaps a slow connection) we
experiance network conjestion (or lag).
Multicast is more like an radio station, broadcasting data at an specific
"frequency" and everyone who is tuned into this frequency can receive the
data sent on the specific frequency.
The use with Muticast networking on IRC Servers & Services can include:
- Server load balancing (Yes, you heard me!).
- Network Redundancy in regards to server connections.
- Multiple Server connection points.
- Bandwidth management.
The basic principal will be that each server on the Multicast IRC Network
gets assigned an initial value or priority. Depending on the outcome of
development (if there should be any such development) either the highest
or
the lowest priority of the available multicast servers gets the request(s)
from the clients on the network.
A possible scenario may look like this:
----------- -----------
| serv1 |-----------------| serv2 |
----------- -----------
() ()
() ()
()()()()()()()()()()()()()()()
() () ()
() () ()
----------- ----------- -----------
| serv3 |---| serv4 |---| serv5 |
----------- ----------- -----------
- Normal TCP Connection (C/N Lines)
() Multicast Network (ID: 224.10.10.1)
serv1 - IRC Services (Priority 1) IP: 192.168.0.1
serv2 - IRC Services (Priority 2) IP: 192.168.0.2
serv3 - IRC Server (Priority 1) IP: 192.168.0.3
serv4 - IRC Server (Priority 2) IP: 192.168.0.4
serv5 - IRC Server (Priority 2) IP: 192.168.0.5
The configuration:
All the servers gets configured with standard IP Addresses (Class A, B or
C).
This is needed because of the fact that an initial IP address MUST be
configured to enable the servers to figure out and join the specified
MultiCast Network ID (In our scenario, 224.10.10.1).
Once the TCP network configuration has been established, the various
servers
needs to connect to each other with means of C/N lines. The links will
more
than likely be that all Servers connect to each other (As per usual),
while
all the IRC Services connects to each other (This is needed for
syncronozation). Then, comes the fun part...
The IRC Services links up to the IRC Servers with use of Multicast
Networking.
This means that there will be NO C/N lines, nor any net-splits due to lag
or
conjestion. We might however, need to implement a new config option for
both
the IRC Services, aswell as the Server, namely an MultiCast IP Address...
Damm pitty that M: is allready used, they should change M: to N: <for
name>
and give us M: for <MultiCast IP> :))))))))
The IRC Services:
Once the IRC Services has been configured with it's initial IP address and
Multicast ID, the services will initiate a UniCast connection between the
number of Services in the chain. The highest (or lowest) priority of the
Services chain (This should be an configuration option) will be an Master
server, while the rest will act as slave servers to the master.
By use of it's UniCast link, the master server will inform the slave
servers
about network usage, which will include various changes made within the
Services databases. Because the Services chain is updated transparently
from
the master server, all our slave servers will also be updated as they need
to.
Another fine feature about this type of MultiCast Network, is that both
the
master and slave Services can listen to netsplits and messages from any
server
anywhere in the network (because they utilize MultiCast
Broadcasting). Should
the master server go down for some reason (Lag, Server Reboot, Network
Upgrade, ect), the slave servers will automatically know about this, and
they
will calculate the highest priority of the servers available, which will
then
rejoin the network - with an up-to-date database!!!
Because of this fact, how more Services you link in your Services Chain,
how
less the chances that your network would be Services-less.
Multicast can also be used within the Services for load balancing. This
can basically work on the principal that the master Services server will
check
it's usage. If the master server detects that it is working to hard, it
can
perhaps by means of multicasting inform one or more of the slave servers,
to
take a certain percentage of the workload from the IRC Network of the
master
server. Because of the fact that all the Services servers can communicate
with the IRC servers, there is no need why this should not be able to work
:)
The possibilities of Multicasting can go on and on :) I am more than
likely
starting to bore you all about this now, so let's just move on to my next
suggested improvement...
For more information on how exactly the broadcasting process and security
in such broadcasting goes, I would recommend reading the IP-MultiCast
HOWTO
document available in the LDP Project.
2. IPv6 Support for IRC Networks & Services:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Say no more ?
We need to get this done at some stage... It doesn't need to be now, but
yeah.
Let's not forget about it?
3. SQL DataBase Support for IRC Services:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WOOOHOOO!! YEAH! :)
Just think of the possibilities here? Web sites which enables users to
send
and receive memo's. Nice HTML pages for nickserv and chanserv access
lists?
Cewl nick browsers for registered nicks? Nickname searches? Nickname
PROFILES (You can even add pictures to the nicknames on an html interface
if
you know your php3 programming)
History of nicknames? This might include history on the nick's abusive
maners,
records of every account where the nickname has been suspended, or klined?
I am really not going to say more here... Be creative, and think it out
for
yourselve, this is key!!!
For compatibility reasons, I would make the suggestion that the SQL
DataBase
be made an additional extra, or DEFINATELY enable / disable it with config
or Makefile options. I would actually recommend to enable / disable this
in
the Makefile, because of the fact that database support for the services
can
make the binaries rather big.
Not everyone will have access to SQL databases, so we can't make Services
depend on this type of database. But the advantages is obviously quite a
bit...
4. Closing:
~~~~~~~~~~~
For a closing, I would just like to point out that in all three suggested
implementations, the services of Andy Church will go and re-write IRC RFC
Standards.
This type of network is *NOT* utilized on ANY IRC Network ANYWHERE in the
world.
IPv6 is also a first to go into IRC Networks.
SQL DataBases will be the first to be used by any IRC Services in the
world.
Andrew, let's take the lead and how them what IRC *SHOULD* and *CAN* be
like,
I know you can do it :))
Best Regards
Chris Knipe
PS: Due to circumstances, I unfortunately can only check my email approx.
once a week. If and when you all out there start to respond, don't be mad
when
you wait long for a reply, I'm telling you now, you will be waiting long
for
a reply...
---------------------------------------------------------------
To unsubscribe, send email to majordomo at ender.shadowfire.org
with "unsubscribe ircservices" in the body, without the quotes.