+++ /dev/null
-Chat subsystem information
-Brian Costello
-btx@calyx.net
-
-Chat / Messaging system
------------------------
-
-I envision a chat system that can be used for a variety of uses, from
-chatting in realtime to file exchange to slide presentations.
-
-Rooms will be able to have invitation lists -- perfect for scheduling a
-private meeting with various people around the world.
-
-Meetings will be scheduled by the system scheduler. The scheduler is not
-part of this project -- the scheduler will do the work of determining a time
-when all participants are free. When a time is decided on, the scheduler
-will call the chat subsystem which will write this schedule to a file. This
-is to make sure that if the chat subsystem is shut down for some reason, it
-will remember the reserved rooms and invite lists.
-
-Rooms
------
-I think a conference call-like system would be good. Chat sessions can be
-scheduled with a predetermined list of people or started manually and their
-invite lists manually made. Either someone is designated a conference
-leader or whoever created the room is the conference leader. The conference
-leader(s) can invite new people to the room, and kick & ban people out of
-the room.
-
-Messages should be able to be sent to anyone on the bbs from the page system
-to the chat system and vice versa.
-
-This can be implemented with the current citadel clients.
-
-Tranfers
---------
-An addition that would be useful here would be the ability to send a file to
-everyone in a room as well as individual users.
-
-This cannot be implemented with the current citadel clients -- I DON'T
-THINK. I'm not sure.
-
-Graphics transfers
-------------------
-The idea is to allow slides to be shown to clients. The transfers mechanism
-will be used to send the graphics so you would be able to send slides to
-everyone or just one user.
-
-This will have to be written into the client (Unix client calls xv, for
-example)
-
-Structures
-----------
-
-/* hold the invite / ban info in this structure. Username and host are each
- * used only if they are specified. This allows banning all hosts from a
- * particular site.
- */
-
-typedef struct s_chat_userlist
-{
- char username[32];
- char host[64];
- struct s_chat_userlist *next;
-} chat_userlist;
-
-typedef struct s_chat_joinlist
-{
- struct CitContext *user_context;
- struct s_chat_joinlist *next;
-} chat_joinlist;
-
-/* Simple chatroom definition */
-
-typedef struct s_chatroom
-{
- char room_name[20];
- char room_password[20];
- time_t scheduled_start;
- time_t scheduled_stop;
- int room_flags;
- chat_userlist *invite_list;
- chat_userlist *ban_list;
- chat_joinlist *join_list; /* Context's of who's in this room */
- chat_joinlist *chanops_list; /* Context's of channel ops */
- struct s_chatroom *next;
-} chatroom;
-
-
-Definitions
------------
-#define CHATROOM_PRIVATE 1 /* Invite only */
-#define CHATROOM_HIDDEN 2 /* Hidden from listing */
-#define CHATROOM_PASSWORD 4 /* Password protected */
-
-Schedule
---------
-The stuff that can be implemented in terms of the currentl client will go
-first. The transfers will come next.
--- /dev/null
+Chat subsystem information
+Brian Costello
+btx@calyx.net
+
+Chat / Messaging system
+-----------------------
+
+I envision a chat system that can be used for a variety of uses, from
+chatting in realtime to file exchange to slide presentations.
+
+Rooms will be able to have invitation lists -- perfect for scheduling a
+private meeting with various people around the world.
+
+Meetings will be scheduled by the system scheduler. The scheduler is not
+part of this project -- the scheduler will do the work of determining a time
+when all participants are free. When a time is decided on, the scheduler
+will call the chat subsystem which will write this schedule to a file. This
+is to make sure that if the chat subsystem is shut down for some reason, it
+will remember the reserved rooms and invite lists.
+
+Rooms
+-----
+I think a conference call-like system would be good. Chat sessions can be
+scheduled with a predetermined list of people or started manually and their
+invite lists manually made. Either someone is designated a conference
+leader or whoever created the room is the conference leader. The conference
+leader(s) can invite new people to the room, and kick & ban people out of
+the room.
+
+Messages should be able to be sent to anyone on the bbs from the page system
+to the chat system and vice versa.
+
+This can be implemented with the current citadel clients.
+
+Tranfers
+--------
+An addition that would be useful here would be the ability to send a file to
+everyone in a room as well as individual users.
+
+This cannot be implemented with the current citadel clients -- I DON'T
+THINK. I'm not sure.
+
+Graphics transfers
+------------------
+The idea is to allow slides to be shown to clients. The transfers mechanism
+will be used to send the graphics so you would be able to send slides to
+everyone or just one user.
+
+This will have to be written into the client (Unix client calls xv, for
+example)
+
+Structures
+----------
+
+/* hold the invite / ban info in this structure. Username and host are each
+ * used only if they are specified. This allows banning all hosts from a
+ * particular site.
+ */
+
+typedef struct s_chat_userlist
+{
+ char username[32];
+ char host[64];
+ struct s_chat_userlist *next;
+} chat_userlist;
+
+typedef struct s_chat_joinlist
+{
+ struct CitContext *user_context;
+ struct s_chat_joinlist *next;
+} chat_joinlist;
+
+/* Simple chatroom definition */
+
+typedef struct s_chatroom
+{
+ char room_name[20];
+ char room_password[20];
+ time_t scheduled_start;
+ time_t scheduled_stop;
+ int room_flags;
+ chat_userlist *invite_list;
+ chat_userlist *ban_list;
+ chat_joinlist *join_list; /* Context's of who's in this room */
+ chat_joinlist *chanops_list; /* Context's of channel ops */
+ struct s_chatroom *next;
+} chatroom;
+
+
+Definitions
+-----------
+#define CHATROOM_PRIVATE 1 /* Invite only */
+#define CHATROOM_HIDDEN 2 /* Hidden from listing */
+#define CHATROOM_PASSWORD 4 /* Password protected */
+
+Schedule
+--------
+The stuff that can be implemented in terms of the currentl client will go
+first. The transfers will come next.
storage and retrieval of large binary objects (blobs) indexed by unique keys.
Please see database.c for more information on data store primitives.
- The message base (msgmain) is a big file of messages indexed by the message
+ The message base (MSGMAIN) is a big file of messages indexed by the message
number. Messages are numbered consecutively and start with an FF (hex)
byte. Except for this FF start-of-message byte, all bytes in the message
file have the high bit set to 0. This means that in principle it is
try for efficiency...)
Each room is basically just a list of message numbers. Each time
-we enter a new message in a room, we slide all the old message-numbers
-down a slot, and probably the oldest one falls off the bottom (in which case
-we must delete it from the message base). Reading a rooms is just a matter
-of looking up the messages one by one and sending them to the client for
-display, printing, or whatever.
+we enter a new message in a room, its message number is appended to the end
+of the list. If an old message is to be expired, we must delete it from the
+message base. Reading a room is just a matter of looking up the messages
+one by one and sending them to the client for display, printing, or whatever.
Implementing the "new message" function is also trivial in principle:
we just keep track, for each caller in the userlog, of the highest-numbered
we ignore all message-numbers in the room less than this, only new messages
will be printed. Voila!
- message format on disk (msgmain)
+ Message format on disk (MSGMAIN)
Each message begins with an FF byte. The next byte will then be MES_NORMAL,
MES_ANON, or MES_ANON2, depending on whether the message in anonymous or not.
this path. (Note that your system name will not be
tacked onto this until you're sending the message to
someone else)
-I ID on orig A 32-bit integer containing the message ID on the
+I Original ID A 32-bit integer containing the message ID on the
system the message *originated* on.
-# ID on local A 32-bit integer containing the message ID on the
+# Local ID A 32-bit integer containing the message ID on the
system the message is *currently* on (obviously this
is meaningless for a message being transmitted over
a network).
R Recipient Only present in Mail messages.
O Room Room of origin.
N Nodename Contains node name of system message originated on.
-H HumanNodeName Contains human name of system message originated on.
+H HumanNodeName Human-readable name of system message originated on.
D Destination Contains name of the system this message should
be sent to, for mail routing (private mail only).
U Subject Optional. Developers may choose whether they wish to
IGnet/Open file transfer.
M Message Text Normal ASCII, newlines seperated by CR's or LF's,
null terminated as always.
+X eXtension field Extension fields are used to carry additional RFC822
+ type lines. X fields contain the X byte followed by
+ the RFC822 field name, a colon, a space, and the value.
EXAMPLE
distribution includes netproc.c, which is basically a database replicator;
please see network.txt on its operation and functionality (if any).
- portability problems
+ Portability issues
At this point, most hardware-dependent stuff has been removed from the
system. On the server side, most of the OS-dependent stuff has been isolated
Win32 stuff).
- "Room" records (quickroom/fullroom)
+ "Room" records (quickroom)
The rooms are basically indices into msgmain, the message database.
As noted in the overview, each is essentially an array of pointers into
That should be enough background to tackle a full-scale room. From citadel.h:
-STRUCT QUickroom {
+struct quickroom {
char QRname[20]; /* Max. len is 19, plus null term */
char QRpasswd[10]; /* Only valid if it's a private rm */
long QRroomaide; /* User number of room aide */
#define QR_NETWORK 2048 /* Shared network room */
#define QR_PREFONLY 4096 /* Preferred users only */
-struct fullroom {
- long FRnum[MSGSPERRM]; /* Message NUMBERS */
- };
-
[Note that all components start with "QR" for quickroom, to make sure we
don't accidentally use an offset in the wrong structure. Be very careful
also to get a meaningful sequence of components --
most recent message in the room. When we are searching for rooms with
messages a given caller hasn't seen, we can check this number
and avoid a whole lot of extra disk accesses.
+
+ There used to also be a structure called "fullroom" which resided in one
+file for each room on the system. This has been abandoned in favour of
+"message lists" which are variable sized and simply contain zero or more
+message numbers. The message numbers, in turn, point to messages on disk.
- The fullroom is the array of pointers into the message file. We keep one
-file for each fullroom array to keep the quickroom file small (and access time
-efficient). FRnum are the message numbers on disk of
-each message in the room. (For NIL, we stick zeroes in both fields.)
-
- user records (usersupp)
+ User records (usersupp)
This is the fun one. Get some fresh air and plug in your thinking cap
-first. (Time, space and complexity are the usernum software rivals.
+first. (Time, space and complexity are the eternal software rivals.
We've got lots of log entries times lots of messages spread over up to nnn
rooms to worry about, and with multitasking, disk access time is important...
so perforce, we opt for complexity to keep time and space in bounds.)
struct usersupp { /* User record */
int USuid; /* uid account is logged in under */
- char password[20]; /* password (for BBS-only users) */
+ char password[20]; /* password */
long lastseen[MAXROOMS]; /* Last message seen in each room */
char generation[MAXROOMS]; /* Generation # (for private rooms) */
char forget[MAXROOMS]; /* Forgotten generation number */
- long mailnum[MAILSLOTS]; /* Message #'s of each mail message */
- long mailpos[MAILSLOTS]; /* Disk positions of each mail */
unsigned flags; /* See US_ flags below */
int screenwidth; /* For formatting messages */
int timescalled; /* Total number of logins */
int posted; /* Number of messages posted (ever) */
char fullname[26]; /* Bulletin Board name for messages */
char axlevel; /* Access level */
- char spare[3]; /* spare bytes for future use */
long usernum; /* Eternal user number */
long lastcall; /* Last time the user called */
};
Private mail is sent and recieved in the Mail> room, which otherwise
behaves pretty much as any other room. To make this work, we store
-the actual message pointers in mailnum[] and mailpos[] in the caller's
-log record, and then copy them into the Mail> room array whenever we
-enter the room. This requires a little fiddling to get things just
+the actual message pointers in a message list for each user (MAILBOXES)
+instead of MSGLISTS. This requires a little fiddling to get things just
right. We have to update quickroom[1].QRhighest at login
to reflect the presence or absence of new messages, for example. And
make_message() has to be kludged to ask for the name of the recipient
projects / citadel.git / commitdiff