Network Working Group CMSC 417 Request for Comments: rfc-echimp-final Section 0101 Spring'00 Obsoletes RFC: rfc-echimp-first-draft April 2000 e-CHIMP is the CMSC 417 Hierarchical IP-based Messaging Protocol (e-CHIMP) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Table of Contents 1. Introduction 2. The e-CHIMP specification 2.1. Overview 2.2. Message 2.2.1 Template Package formats 2.2.1.1 User-client communication 2.2.1.2 Client-client communication 2.2.1.3 BNF_ERR and TIMEOUT 2.2.2 Message format in 'pseudo' BNF 3. Message details 3.1 Connection Management 3.1.1 Configuration File 3.1.2 Connection 'liveness' 3.1.3 Establishing the e-CHIMP-backbone topology 3.1.4 Clients resume from crashes 3.2 User Management 3.2.1 User Programs 3.2.2 NICK request : ask for a nickname as specified 3.2.3 Join group : User joins to a named group 3.2.4 Leave a named group 3.3 Group Operations 3.3.1 Group Structure 3.3.2 Group Leader 3.3.3 Client Joins Group 3.3.4 Create a new group 3.3.5 Client Leaves Group 3.3.6 Group Leader Management 3.3.7 Designated Coordinator 3.3.8 Database in Designated Coordinator 3.4 Client queries and commands 3.4.1 Client Query Group Leader 3.4.2 Client Query Groups List 3.4.3 Update Group Leader 3.4.4 Client Query Nickname for NICK 3.4.5 Client Query Nickname for WHO 3.5 Server Routing Management: 3.5.1 Routing updates message format 3.5.2 How to send updates 3.5.3 No heart-beat messages needed 3.6 Sending messages 3.6.1 User-client interaction 3.6.1.1 SEND 3.6.1.1.1 User u1 sends a private message to another user u2. 3.6.1.1.2 User u1 sends a group message to group g1. 3.6.1.2 LIST 3.6.1.2.1 List current groups in e-CHIMP network 3.6.1.2.2 List users in a group 3.6.1.3 WHO 3.6.1.3.1 Query a specific user (nickname) 3.6.1.3.2 Query all users in e-CHIMP network 3.6.2 Client to Client Replies 3.6.2.1 User in Query 3.6.2.2 Private User Data 3.6.2.3 Group User Data 4. Misc. Implementation Issues -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 1. Introduction The e-CHIMP protocol specifies the interactions between the different entities and provides a teleconferencing mechanism between users. It is run on different machines in a distributed fashion. It is a text-based protocol in which users can interactively communicate with other users connected to the e-CHIMP network. 2. The e-CHIMP specification 2.1. Overview There are three main entities : Servers (S), Clients (C) and Users (U). Additionally, for simplicity of design, we require a new enitity called the e-CHIMP Designated Coordinator (D). There is only one Designated Coordinator who is responsible for the various management functionalities of the entire e-CHIMP network. 2.2. Message 2.2.1 Template packet format 2.2.1.1 User-client and client-server communication 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Message (depends on the message type) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 8 bits 2.2.1.2 Client-client communication Data Packet Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Rest of the message (if any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "Rest of the message (if any) is terminated by '\0' (no padding). Acknowledgement Packet Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | Rest of the message (if any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version : 4 bits, 0110 FOR ALL (DATA AND ACK) MESSAGES Msg Type : 12 bits Src Id : 8 bits Dst Id : 8 bits *** Go-Back-N connection is simplex, so either "Sequence Number" or "Acknowledgement Number" is needed, depending on the type (data packet or acknowledgement packet) of message. *** You can add additional types of messages which will NOT change this specification. For example, messages needed in a three-way-handshake connection setup. *** When adding your own message types, we recommend using the range from 0x100 to 0x1FF to distinguish them from the numbers used in this specification. 2.2.1.3 BNF_ERR and TIMEOUT Whenever a name (group-name or nickname) is invalid, a "BNF_ERR" will be sent. Similiarily, whenever a timeout error occurs, a "TIMEOUT" message is sent. This applies to both user-client and client-client communications Msg Type : 0x0FF (BNF_ERR) Msg Type : 0x0FE (TIMEOUT) 2.2.2 Message format in 'pseudo' BNF ::= + (up to 255 characters, case in-sensitive) ::= #+ (up to 255 characters, case in-sensitive) ::= | | nil ::= [a-z] | [A-Z] ::= [0-9] All other formats are specified in individual message formats in the remaining sections. 3. Message details 3.1 Connection Management There will be four different physical connections that the protocol needs to address. They are: TCP UDP UDP TCP User <-----> Client <-----> Server <-----> Client <-----> User The Desingnated Coordinator (as described later) is treated as a special client. Reliable client-client communications should be implemented by Go-Back-N (GBN) protocol, and, for simplicy, GBN connections are simplex. 3.1.1 Configuration File Both servers and clients will read a configuration file when they start up. The file is similar to the configuration file used in a previous project. Here is a sample configuration file: --------- start of file (please use your own ports) -------- ; Designated Coordinator at 0 ; The second column denotes the node's e-CHIMP ID ; "node" means a server client 0 tracy node 1 tracy node 2 wolfe node 3 wolfe node 4 poirot client 5 poirot client 6 poirot ( ; costs between client-node are always 0 establish node 1 port 55512 node 2 port 55521 cost 1 name link12 establish node 1 port 55514 node 4 port 55541 cost 8 name link14 establish node 2 port 55523 node 3 port 55532 cost 2 name link23 establish node 3 port 55534 node 4 port 55543 cost 2 name link34 establish client 0 port 55501 node 1 port 55510 cost 0 name link01 establish client 5 port 55552 node 2 port 55525 cost 0 name link52 establish client 6 port 55563 node 3 port 55536 cost 0 name link63 ) --------- end of file -------------------------------------- Each node is now uniquely identified by the hostname:port pair. All servers and clients should have such a global mapping. 3.1.2 Connection 'liveness' The peer members of the each of these UDP connections need to have some kind of heart-beat or equivalent mechanisms to detect that the connection is active. 3.1.3 Establishing the e-CHIMP-backbone topology Use the same mechanism as your Distance Vector Routing project. That is, when the nodes (clients and servers) start up, they will parse the same configuration file with ONE event set which defines the e-CHIMP-backbone topology, as well as the clients attached to them. Each server then starts to run forever unless it is killed manually. 3.1.4 Clients resume from crashes Recall that a client only attaches to one server. Only the attached server sends routing updates to the client; there is no need for a client to send routing updates to the attached server. A client can go down for a while then go up. When a server detects that a client is no longer unreachable, it will set the cost to INFINITY. When that client resumes, it then hears the routing updates again from that attached server, therefore that client is automatically re-attached to the server. 3.2 User Management This section describes how a user joins and leaves the e-CHIMP network, nicknames etc. Please note that the user and client communicate through TCP and each client maintains a nickname list of all attached users. 3.2.1 User Programs The user program starts up with a command line argument specifying which client to connect to, for example: % user_program -h The interactions between a human user and user program (i.e., how to give command and how user program displaying message) is not specified here, it is up to you. 3.2.2 NICK request : ask for a nickname as specified In order to join the e-CHIMP network, each user should first send a "NICK" request to the attached client, C. NICK Message format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Nickname'\0' (variable length, no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x030 (NICK) Nickname: User provided nickname Client C first checks the format of nickname. If the format is correct, it then contacts the Designated Coordinator (D) to check against duplication. If D responds ok, C responds to the user with a "NICK_OK". If the format is invalid, C responds with "BNF_ERR". If C cannot not get a successful response from the D before timeout, it will respond a "TIMEOUT". If D responds C with a nickname collision, C responds the user a "NICK_EXISTS". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | not used | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type: 0x031 (NICK_OK) Msg Type: 0x032 (NICK_EXISTS) 3.2.3 Join group : User joins a named group After a nickname is verified, the user can join a group by sending a "JOIN" message to its client (C): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | '\0''\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type: 0x033 (JOIN) Each client maintains a list of all local nicknames and their group membership (if any) in order to prevent duplicates. C checks if the format of nickame and group name is valid. If not, C replies a "BNF_ERR". If the group already exists in C's database, it just adds this user to the database, and replies with a "JOIN_OK" directly to the user. If the group is new to C, it asks the Designated Coordinator for the ID of the group leader. A new group is created at this time if the group name is not in Designated Coordinator's database. Please see section 3.3. If the group name is in Designated Coordinator's database and the Designated Coordinator responds an ID of the group leader, C will send a "CLIENT_JOIN_GROUP" message to the returned group leader. Please see section 3.3. C replies to the user with either "JOIN_OK" (including the case if a new group is formed) or "TIMEOUT" (if it timeouts). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | not used | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type: 0x034 (JOIN_OK) 3.2.4 Leave a named group A user can leave a group explictly by sending a "LEAVE" message to its client, C: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | '\0''\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type: 0x037 (LEAVE) If the given group name and nickname are valid, C responds with "LEAVE_OK". If the group-name or nickname does not exist in C's database, it replies with a "LEAVE_NOT_EXIST". If either group-name or nickname is not in valid format, it replies with a "BNF_ERR". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | not used | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type: 0x038 (LEAVE_OK) Msg Type: 0x039 (LEAVE_NOT_EXIST) If the attached client realizes that a user is the last one locally existing in the group, and, it is not a group leader, it sents a "CLIENT_LEAVE_GROUP" message (see section 3.3) to the group leader to leave the group, if that client is the group leader, nothing is sent. 3.3 Group Operations All client-client communication should be end-to-end reliable. This should be done using the Go-Back-N protocol. 3.3.1 Group Structure A group is a set of users that want to communicate on a specified topic. It is equivalent to an IRC channel. When a user intends to join a group, it effectively requires that the client it is connected to joins that group. In this section, we look at a group as a set of clients (derived from a set of users). 3.3.2 Group Leader Each group has a `group leader' -- which is one of the clients that is part of the group. The group leader maintains information about all the members of the group. It sends the entire list of group members to all group members. All current group members acknowledge this messge. 3.3.3 Client Joins Group When a new member (client) wants to join the group, it first finds out who the group leader is (this is done through the Designated Coordinator, whose functionality and associated message formats will be described later). It then informs the group leader of its intent to join. The group leader will inform this member about all the other members of the group, as well as inform all the other members about this new member. For simplicy, the group leader sends out the whole list of group members. These interactions must be done reliably. Message Format for Contacting Group Leader to join a group: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type: 0x042 (CLIENT_JOIN_GROUP) Src Id: Group Member (Client) ID Dest Id: Group Leader (Client) ID Message Format for updated group membership (sent from group leader to other group members, and only be sent upon updates): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Num. of Members(N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | '\0''\0'........'\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-++-+-+-++-+-+ Msg Type : 0x043 (GROUP_MEMBERSHIP) Src Id : Group leader ID Dest Id : Group member ID Num. of Members: Number of members included in this message Member names : Each is terminated by a null character '\0' Message format for group member's ACK: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type: 0x044 (GROUP_MEMBERSHIP_ACK) Src Id: Group Member (Client) ID Dest Id: Group Leader (Client) ID 3.3.4 Create a new group This happens when the first user is added into a group whose name is not in Designated Coordinator's database. 3.3.5 Client Leaves Group When a member leaves the group, it tries to inform the group leader if possible. This message need not be reliable, and also it is possible that no message is sent, e.g., if the member fails. Since the group leader sends the entire group membership periodically, each member could get an up-to-date list of members. If at any time, a group leader does not get an ack from a member after repeated attempts at distributing group membership information, it concludes that the member is lost and informs all the other members of the group. Message Format for Contacting Group Leader to leave a group: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type: 0x045 (CLIENT_LEAVE_GROUP) Src Id: Group Member (Client) ID Dest Id: Group Leader (Client) ID Please also refer to previous section for other message formats (membership updates, and ack to membership updates). 3.3.6 Group Leader Management It is also possible that a group leader fails or leaves, in which case the group would be temporarily without a group leader. In this case, all the members will realize that the group leader is gone, since the ``GROUP_MEMBERSHIP'' message from the group leader will not arrive. In this case, all members will initiate the process of choosing a new group leader. Each member, C, will use a random timer to send a reliable message to the Designated Coordinator (D). The message would indicate C's knowledge as to who the current group leader (CGL) is (i.e., the one that just went away) and requesting at D install C as the new group leader. The "SEIZE_GROUP" message is as the follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | CGL | .....| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...(group name terminated by '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type: 0x050 (SEIZE_GROUP) Src Id: Group Member ID Dest Id: Designated Coordinator CGL: Current Group Leader ID If CGL indicated in the message from C, is the same as the Designated Coordinator's knowledge of the group's leader, then the Designated Coordinator, installs C as the new leader for the group, and replies a ``SEIZE_GROUP_OK''. This information is stored by the Designated Coordinator in its permanent storage. If on the other hand, CGL does not match the Designated Coordinator's knowledge of the group leader, then C is refused, and is informed with a message ``SEIZE_GROUP_FAIL'' as to who the group leader is (ActGL). The "SEIZE_GROUP_OK" message return from Designated Coordinator is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x051 (SEIZE_GROUP_OK) Src Id : Designated Coordinator Dest Id : Group Member ID If C gets the above message, it will install itself as a group leader, and starts sending out ``GROUP_MEMBERSHIP'' messages to all the group members. The "SEIZE_GROUP_FAIL" message return from Designated Coordinator is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledge Number | ActGL | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...(group name terminated by '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x052 (SEIZE_GROUP_FAIL) Src Id : Designated Coordinator Dest Id : Group member ID ActGL : Actural current group leader ID In this case, C will then try to join this group by sending a reliable message to ActGL (it is like C is joining the group afresh). 3.3.7 Designated Coordinator The Designated Coordinator is like an e-CHIMP client. It attaches to only one server. However, no users can attach to the Designated Coordinator. The Designated Coordinator is assigned the ID 0, and so the clients and the servers will have to route their packets towards the ID 0 entity to reach the designated server. It can be assumed for this implementation, that the Designated Coordinator will always be available. To ensure that the nicknames and the group names are globally unique, all assigned nicknames and group names are stored at the Designated Coordinator. Each client checks with the Designated Coordinator the availability of a name before allowing its use. The first client to claim a name is given the name and the Designated Coordinator retains a copy of the name to check against duplication. 3.3.8 Database in Designated Coordinator The Designated Coordinator is essentially a database implemented as two structured files. The first file "nicknames.db" stores a list of all alloted nicknames, EACH OCCUPIES ONE LINE. A sample file looks like this: nickname-1 nickname-2 . . . nickname-n The second file, "group_info.db", stores a list of all group names, and for each group alloted, the id of the client which serves as the leader for that group. These two fields MUST be separated by at least one white space. *** NOTE: Only character 0x20 and TAB are considered as white space, a new-line character is NOT considerd as white space in this case. groupname-1 group-leader-1 groupname-2 group-leader-2 . . . . groupname-n group-leader-n 3.4 Client queries and commands 3.4.1 Client Query Group Leader As described eariler, a client (C) queries a group leader by sending a "SEIZE_GROUP" to the Designated Coordinator (D), and, fill 0 (i.e., the Designated Coordinator) as the ``CGL'' field. In this case, the actural current group leader will be returned. 3.4.2 Client Query Groups List A client (C) may query the Designated Coordinator for a complete list of group names. In this case, C sends a "QUERY_ALL_GROUPS" to Designated Coordinator (D): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x065 (QUERY_ALL_GROUPS) Src Id : C Dest Id : D (i.e., 0) D sends back a "QUERY_ALL_GROUPS_RESP" as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Num. of Groups (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | '\0''\0' ......'\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x066 (QUERY_ALL_GROUPS_RESP) Src Id : D (i.e. 0) Dest Id : C Num. of Groups : Number of groups included in this message Group names : Each is terminated by a null character '\0' 3.4.3 Update Group Leader Client can add a name to the Designated Coordinator's list, or can alter the identity of the group leader as would be needed for group leader management. This might fail at the Designated Coordinator (if the name already exists etc). Please refer to section "Group Leader Management". 3.4.4 Client Query Nickname for NICK When a client (C) ask the Designated Coordinator (D) to check against a new Nickname. C sends D a "CLIENT_NICK" message as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x067 (CLIENT_NICK) Src Id : C Dest Id : D (i.e. 0) D checks if is already in its database, if so, it responds with a "CLIENT_NICK_EXIST", otherwise, D adds the nickname into its database, and responds with a "CLIENT_NICK_OK". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | '\0' (no padding)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x068 (CLIENT_NICK_OK) Msg Type : 0x069 (CLIENT_NICK_EXIST) Src Id : D (i.e. 0) Dest Id : C 3.4.5 Client Query Nickname for WHO When a client (C) ask the Designated Coordinator (D) to check against a new Nickname. C sends D a "CLIENT_USER_IN_COORDINATOR" (please see section 3.6.1.3.1). D responds similarly to section 3.4.4, except that if doesn't exist in its database, D will not not add it into its nickname database. Return message: "CLIENT_USER_IN_COORDINATOR_YES" or "CLIENT_USER_IN_COORDINATOR_NO" (please see section 3.6.1.3.1) 3.5 Server Routing Management: The e-CHIMP-backbone basically works as a datagram network. Servers only forward messages hop by hop. You must use the distance vector routing algorithm to manage the routing withing the e-CHIMP-backbone. 3.5.1 Routing updates message format This format is basically the same as the one used in project 4 (the DV routing project), except for the version number. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | version | Num. Updates | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dest_0 | min_cost_0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............................ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dest_n | min_cost_n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x077 (ROUTING_UPDATES) type : 0x7 for this assignment version : 0x02 3.5.2 How to send updates Each server should ALWAYS send out ALL updates, in order to make both versions of implementation (with or without a distance table) compatiable. Therefore, if you are using a distance table and ONLY send out updates, you will need to modify your code a bit. This should require only a small amount of work. 3.5.3 No heart-beat messages needed Because each node sends out its entire routing table periodically, you DO NOT need to use separate heart-beat messages any more. Use routing table updates to detect node failure. 3.6 Sending messages 3.6.1 User-client interaction This section lists all the supported commands a server can send to the attached client: NICK, JOIN, LEAVE, SEND, LIST, WHO. NICK, JOIN and LEAVE have been described in section 3.2. We describe SEND, LIST and WHO as follows. 3.6.1.1 SEND Send a message to either another user or a group of users. 3.6.1.1.1 User u1 sends a private message to another user u2. u1 first sends a "PRIVATE_USER_DATA" message to its client, C1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | '\0''\0' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x070 (PRIVATE_USER_DATA) When C1 receives such a user message, C1 locates the client (C2) to where u2 attached to (by broadcasting "CLIENT_USER_IN" message, please see section 3.6.2). C1 then set up a reliable Go-Back-N connection with C2, forword the message to C2, C2 then sends it to u2, and sends an ACK (CLIENT_PRIVATE_USER_DATA_DONE) back to C1. Message "CLIENT_PRIVATE_USER_DATA" sent from C1 is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x071 (CLIENT_PRIVATE_USER_DATA) Message "CLIENT_PRIVATE_USER_DATA_DONE" sent from C2 as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x072 (CLIENT_PRIVATE_USER_DATA_DONE) 3.6.1.1.2 User u1 sends a group message to group g1. u1 sends a "GROUP_USER_DATA" message to the attached client, C. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | '\0'Message'\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x073 (GROUP_USER_DATA) Since C knows the group's membership, say, g1={C1, C3, ..., CN}, C will do a unicast to each of C1...CN individually. That is, sends a "CLIENT_GROUP_USER_DATA" to each of C1...CN via Go-Back-N connection. Each of C1...CN then sends ``CLIENT_GROUP_USER_DATA_DONE'' back to C after successfully forwarding the message (a TCP message) to the destination user(s). If a client times out, it sends "TIMEOUT" back to C. How C reports timeout to u1 is left to you, since it is a local message. Message "CLIENT_GROUP_USER_DATA" is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | '\0'Message'\0' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x074 (CLIENT_PRIVATE_USER_DATA) Message "CLIENT_GROUP_USER_DATA_DONE" is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x075 (CLIENT_PRIVATE_USER_DATA_DONE) 3.6.1.2 LIST The LIST command allows a user to query for a list of the current groups in the e-CHIMP Network, or a list of users in a given group. 3.6.1.2.1 List current groups in e-CHIMP network To get a list of all groups, the user sends a "LIST_GROUPS" to its client, C: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | not used | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x080 (LIST_GROUPS) C then sends "QUERY_ALL_GROUPS" to the Designated Coordinator (D) to get a list of groups (please refer to section 3.4.2). If D responds successfully, C replies to the user with a "LIST_GROUPS_RESP": 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Num. of Groups (N) | '\0'..| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (cont.)'\0' .................... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .....'\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x081 (LIST_GROUPS_RESP) Num. of Groups : Number of groups included in this message Group names : Each is terminated by a null character '\0' 3.6.1.2.2 List users in a group To get a list of users of a named group, the user sends a "LIST_GROUP_USERS" to the attached client, C: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x082 (LIST_GROUP_USERS) C first checks if is in valid format, if not, it sends out a "BNF_ERR" message. C then contacts each client in that group for a list of locally attached group-member. The client-client message "CLIENT_LIST_GROUP_USERS" format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | '\0'Message'\0' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x083 (CLIENT_LIST_GROUP_USERS) It then collects (remember that client-client connection should be reliable) all the responses ("CLIENT_LIST_GROUP_USERS_RESP", as specified below) to get an entire list of users in the group, creates a "LIST_GROUP_USERS_RESP" message and sends it back to the user. The client-client "CLIENT_LIST_GROUP_USERS_RESP" message is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | Num. of Users (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | '\0''\0''\0'...'\0' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x084 (CLIENT_LIST_GROUP_USERS_RESP) The client's response (with user) "LIST_GROUP_USERS_RESP" is as the follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Num. of Users (N)(2-bytes) |'\0'| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | '\0''\0'..... '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x085 (LIST_GROUP_USERS_RESP) Num. of Groups : Number of groups included in this message Group name : Variable length string terminated by '\0' User names : Each is terminated by a null character '\0' If it times out, C responds with a "TIMEOUT" message. 3.6.1.3 WHO The WHO command allows a user to query for a list of users currently in the e-CHIMP Network, or for a specified user. 3.6.1.3.1 Query a specific user (nickname) A user can ask if another specific user is in the e-CHIMP network by sending a "USER_IN_COORDINATOR" message to its client, C: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | '\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x086 (USER_IN_COORDINATOR) C then contacts the Designated Coordinator (D) for the answer by sending a "CLIENT_USER_IN_COORDINATOR" as the follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | '\0'(no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x087 (CLIENT_USER_IN_COORDINATOR) Src Id : C Dest Id : D (i.e., 0) D will respond either "CLIENT_USER_IN_COORDINATOR_YES", or "CLIENT_USER_IN_COORDINATOR_NO": 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledge Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x088 (CLIENT_USER_IN_COORDINATOR_YES) Msg Type : 0x089 (CLIENT_USER_IN_COORDINATOR_NO) Src Id : D (i.e., 0) Dest Id : C C's responses to the query user is left to you, since it is a local message. 3.6.1.3.2 Query all users in the e-CHIMP network For a user to see if a specific user is in e-CHIMP network, a "LIST_ALL_USERS" is sent to its attached client, C. C then contact the Designated Coordinator (D) for a complete list of nicknames. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | not used | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x092 (LIST_ALL_USERS) "CLIENT_LIST_ALL_USERS" sent from C to D for a complete list of nicknames: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x093 (CLIENT_LIST_ALL_USERS) Src Id : C Dest Id : D (i.e., 0) D then responds with "CLIENT_LIST_ALL_USERS_RESP" as the follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | Num. of Nicknames follow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | '\0''\0'...'\0' (no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x094 (CLIENT_LIST_ALL_USERS_RESP) Src Id : D (i.e., 0) Dest Id : C 3.6.2 Client to Client Replies 3.6.2.1 User_in Query A client (C) can receive "CLIENT_USER_IN" queries from other clients. The client then replies with "CLIENT_USER_IN_YES" or "CLIENT_USER_IN_NO": "CLIENT_USER_IN" message from other clients: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | '\0'(no padding) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x095 (CLIENT_USER_IN) Src Id : query client's ID Dest Id : C 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x096 (CLIENT_USER_IN_YES) Msg Type : 0x097 (CLIENT_USER_IN_NO) Src Id : C Dest Id : query client's ID 3.6.2.2 Private User Data A client (C) can recieve "CLIENT_PRIVATE_USER_DATA" from other clients. C checks if the included is currently attached to it. If yes, C will send it to that user, then send "CLIENT_PRIVATE_USER_DATA_ACK" back to the sender client. Otherwise, C replies to the peer client with a "PRIVATE_USER_DATA_NOT_EXIST". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgement Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x098 (CLIENT_PRIVATE_USER_DATA_ACK) Msg Type : 0x099 (CLIENT_PRIVATE_USER_DATA_NOT_EXIST) Src Id : C Dest Id : sender client's ID 3.6.2.3 Group User Data A client (C) can recieve "GROUP_USER_DATA" from other clients. C checks if the included is in its database. If yes, it sends the message to all local users belonging to that group, it then sends "GROUP_USER_DATA_DONE" back to the sender client, if all acks from users are collected. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Msg Type | Src Id | Dest Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type : 0x0A0 (GROUP_USER_DATA_DONE) Src Id : C Dest Id : sender client's ID 4. Misc. Implementation Issues o Nicknames, group names are case-insensitive o All multiple bytes numbers should be in network byte order. o All client-client communications need to use Go-Back-N. o All nicknames, group-names, and user-user data should be terminated by null character '\0'. o There are no paddings within messages. o It is possible that for a pair of clients, say, C1 and C2, have mulitple Go-Back-N connections built in between. For example, u0 and u1 are attached to C1, and want to talk to u3 and u4 (both attached to C2) respectively. In such cases, you should make sure that the "Sequence Numbers" for all connections do not not overlap with each other. o You can safely assume that the maximum number of active connections at any time is 64 for simplicy.