TunaChat

This is really outdated, but the basic idea still holds up. Times and stuff are very wrong, due to be writing this when I had very very little experience, also ignore the protocols, altho most still work decently in their discussed state. Any ideas suggestions, etc.. should be mailed to me, go back a few pages for address. I had very little expereince with anything but single server based chat systems, and have a few ideas that I really need to write down, and possibly update this doc. Im looking at throwing out the nick and group registration too. All input is welcome.

Theory:

Group-server is the central server. It holds the database of nicknames and such things. It also knows about all groups, users in them, and their status of each user (moderator, manager, vice-manager, etc...). When a user wants to create a group, it tells the Group-server (UDP), which adds you to its list of Client-servers. From then on, when another user tries to join that group, they talk to the Group-server (UDP) and find out about the Client-server. They will then make a connection (TCP) with the Client-server of the group and the Group-server will know about the two people in the group, the group's name, and everyone's rights/privileges in that group. When a user quits, the Client-server notifies the Group-server which removes the user from its currently logged in database. Clients also can connect straight to other Client-servers, at which point the Client-server can notify the Group-server, or they can be anonymous. Group-servers will ping all Client-servers every hour to see if they are still alive. Client-servers will ping their Clients more often, 3 minutes for users that have not communicated to their Client-server. These pings will not affect the idle times of the pingee.

Local (inside your current group) messages are sent to the Client-server which then relays them back to all other users in its group. Messages can be general (to all users in group) or they can be specific (to a certain user), but be globally read (like mbbs user-directed messages).

Private messages are sent to the directed user by obtaining their address from the Group-server. Once known, the message is sent to the user. The user gets message and returns random number to sender, who then returns the number, if the numbers match, the message is real, otherwise it was faked.

Actions are just messages that are displayed a certain way to one user and a different way to other users. If user ick decides to drop anvil on user synk, then everyone sees: "ick has just dropped anvil on synk" and synk woud see: "ick has just dropped an anvil on you" (or something like that). Also actions can be like: "ick is sighing" (which everybody sees). Actions will also begroup specific. (see Flags)

Announcement of new groups will be sent from the Group-server to all Client-servers. Client-servers will then check to see if their Clients have new group notification turned on, and then send appropriate CLIENTS a special group announcement message.

Notification of new users will be chosen by each Client. The Client-server will be notified of the Client's choice, which will notify the Group-server. The group server then logs which Client-servers want to know about about notification of a certain user login, and the Client-servers also log which Clients want to know. When that certain user connects to the Group-server, the Group-server notifies the correct Client-servers about the connection. When that user disconnects, the same thing happens. When a user that requested the info disconnects or turns off the notification, the Client-server notifies the Group-server which then removes the person from its list. The log of the Group-server will be composed of the users to be checked, and which Client-servers wish to know about those users. The Client-server keeps a similar log of which Clients want to know about what users.

Pings will just be simple messages that are meant to be sent and upon receiving, are to be returned. Pings will carry a ping number on them, that will be irrelevant to the pingee, but the pinger will time how long it took for that message to return. If the correct ping number was not returned, a ping was missed.

User list requests are handled the following way:

Complete user list:
Client will send request to Group-server for entire user list. If it has been 30 minutes since last broadcast ping to Client-servers, the Group-server will now send a broadcast ping.

Current group user list:
Client will send request to its Client-server for the current group's user list.

Other group user list:
Client sends request to the Group-server to request location of the Client-server. It will then send request to the Client-server for a user list. Idle-time will not be given whenj getting the entire user listing from the group server. It will however be given when asking about just one group or user. The Client-server will give back the idle time (time since user last communicated with that Client-server) along with the other information. When getting user list of all Groups that a certain user is in, that user's Client will ask its Client-servers about their user lists, therefore returning idle times.

Joining multiple groups just add more connections to the Client (TCP). A special key would switch the focus of the Group that was being spoken to.

Invisible groups are just like normal groups, except that the Group-server does not notify anyone outside of your group about your Group.


features and notes:

  • local channel messages
  • *private messages
  • *announcement of new groups
  • *notification of new users
  • *joining multiple groups
  • *actions (mbbs kinda stuff) (groups w/ actions, no actions [action restricted, action booted])
  • database storage
    ( nicknames ) ( group-names: moderator, manager, both )
  • pings
  • user-lists
  • idle-time
  • find best manager (best ping time)
  • logins available through client-servers, invisible to group-servers
  • group-servers talk to each other for info to keep it synchronized (NIS system)
  • clients also talk to icb and irc
  • be able to throw up your own little universe at an previously agreed upon time and let friends connect to have a private meeting apart from the rest of the world
  • grok SIGWINCH but not suits and ties
  • spliting of the client-server socket into 2 parts, admin and group. admin will be for registering, user lists, etc... group port will be for actual talking of groups.
  • authenticating GROUP-SERVERS with only give info to registered users
  • "/m! user blah blah" sends "blah blah" to everyone in group but
  • "/restrict user" restricts entry from one user
    Back