Release notes to version 0.16 ----------------------------- March, 2002 Many updates, new code, cleanups, and bug fixes! Too much to mention, but here's a silly attempt: there's now support in cnd for foreign clients, so that you can tie cnd to a "foreign" protocol system such as IRC, or integrate it with a different conferencing system. You can find an API in cnd/client/foreign_api.h, and example code in cnd/client/example_client.c . To implement this, client protocol handlers were implemented in cnd. This work is almost finished; it means that there is a very clear and very defined way in which the client code interacts with the server code. Then, the protocol has been extended as well as the code to allow the server to use different transport mechanisms than TCP to send data to clients (the server-server transport mechanism is still WWCP MCAST over TCP/IP). This means that if "n" clients listen to a radio station, then instead of sending the data "n" times in TCP/IP connections, it is only sent once using, for example, UDP broadcast. In fact, this is the only transport mechanism ("medium") currently implemented. Others will follow, such as Ethernet multicast and IP multicast. New as of this release is a client lib (in the "client" directory from the package root) that helps you to implement WWCP clients. It implements WWCP level 3 clients. The 'tap' client has not been touched, and is hereby declared hopelessly out-of-date. The Network Interface Layer now implements write queues and non-blocking writes. This means that the code now is independent of network outages, and will not block for no apparent reason at all. The network code has been thoroughly tested. The mempool has been enhanced: it stores the malloc.codes list in an array, so that useful information can be obtained online through the diag interface. Using this tool, a few memory leaks have been tracked down. The other components, (cdsd, udsd, tap) have not received much work. Release notes to version 0.15 ----------------------------- Version 0.15 has never been released. Release notes to version 0.14.2 ------------------------------- Februari, 1998 Added string identifiers to all hash tables, and some minor work was done. Release notes to version 0.14.1 ------------------------------- November, 1997 Autoconfig has been added to the package. This makes the compilation process much easier. Also, numerous bugs here and there have been fixed, and some wwcn client level 3 features (ID, JOIN, LIST) have been implemented. This work is still far from complete. A foreign client protocol interface has been added in cnd. You can use it to connect WWCN "back-to-back" to, for example, an IRC server. A user simulator "usersim" has been added (using the IRC client protocol), and a crude WWCP level 3 client called "tap". Release notes to version 0.14 ----------------------------- Spring, 1996 A lot of things changed in version 0.14, especially for the admins. Yes, there are admins now. The following elaborates the new features. /reg ==== Usage: REG The REG command has been in the server already for a while, albeit in a somewhat cloaked manner. I still suspect a few bugs in there, so it's not yet ready for the entire world. Play around a bit and please report anything suspicious to me. The REG command will register a user into the database (usually etc/users.db); this information is used to recognize a user (see the ID command). Currently, being registered does not have any advantages; however, the User Directory Service will only accessible to registered users, and in the end (somewhere near 2005) each user is required to register. The server will fork and exec() a mail process, that will send a (server wide, not network wide) ID to the client along with a password. If the email address is valid and belongs to the right person, then that person can use the ID and the password to access WWCN. Note that in a future release, an admin is able to exclude free mail addresses; these are too easy to get. /id === Usage: ( /quote or /raw) ID The ID command is used to identify oneself. As no off the shelf IRC client will understand this command, it will have to be used with "/quote". The userid and password are the ones you received by mail after using the /reg command. You should use this command in a startup script of some sort, as you have to use it at the start of each session. The ID and password are tied to a particular WWCN server, so the client should keep a table of (server, id, password) tuples. After a timeout of 5 minutes, the server will remind you of the fact that you haven't identified yourself. This will have no further consequences. /admin ====== With /admin you can identify yourself as being an administrator. Without parameters, the command tells you if you're an active admin or not. To become an active admin, you should type "/admin on ", the password being the one mentioned in the "admin" section of the config file (see further on). You should connect from a host matching one of the host masks in your "admin" section. You can become a passive admin (no different from other users) by typing "/admin off". /connect ======== Usage: /CONNECT ( CN | UDS | CDS ) (admin only) eg. if you want to connect to a conferencing server with ID 12, you would type "/connect cn 12". There must be a server with ID 12 in the peer_connects section of the config file. It works the same for connecting to channel directory servers (CDSes): "/connect cds 15" will connect your server to CDS with ID 15, if such an entry is in the cds_connects section in the config file. You can examine this table with the command "/connect" without parameters. It will show you the host names, port numbers, ID, types and state. The state may sometimes look peculiar, they're mainly for debugging. More documentation about these will follow later. System channels =============== System channels are local channels to which a server sends notices about things going on in the intestines of the server. Currently, the following types have been defined: security server security (users becoming admins etc) connects all incoming and outgoing connections critical notices that may indicate (fatal) internal errors routing all routing information and its processing proterr protocol errors client notices about particular clients For each type, a channel name can be identified in the config file (see further on). A channel may be "admin only" or public. It is advised that the security system channel be admin only. CONFIG FILE =========== Two sections are new: "admin" and "serverchannels". The admin section looks as follows: admins = { * } where ADMIN_ENTRY is "" { * } eg. admins = { "Gerrit Hiddink" { wit387401.student.utwente.nl *.cs.utwente.nl } fruttie "Jan Kuipers" { cal012034.student.utwente.nl } frottie } This would define two admins, each with a set of host masks and a password. The "serverchannels" section looks like: serverchannels = { * } where SERVERCHAN is '=' eg. serverchannels = { connects = sys.local.connects admin critical = sys.local.critical admin routing = sys.local.routing public protocolerrors = sys.local.proterr public security = sys.local.security admin client = sys.local.client public } Also, there's a new log type: "security_logfile", If you want to log security notices (sure you want that) you should add it to the config file along the other log files. Have fun!