
Message Server 1
|
|

Message Server 2
|
|

|
|
|
Front Server
|
|
|

Client
|
|
1. Client Login
0. Allowed commands during this stage
VER, USER, PASS, GOTO
1. Initial version nagotiation
Client makes connection with the FrontServer(FS). To connect use TCP/IP
connection on SERVER:PORT. After the client is connected it sends:
(VER protocol_version(float)
client_name(char))
> VER 0.1 TEST_CLIENT
And the FS responds with
< VER OK
If client capabilities are ok, or
< VER NOK
<o> close connection
If the capabilities are not correct. For now the only valid protocol
version is 0.1
2. Requesting client authorization
The client sends to FS request for entering into the IM system. It
sends:
> USER my_user_name
The server responds with
< USER my_user_name MD5
MD5_MESH_STRING
The client have to send his/her password, encrypted using the MD5
algorithm, for checking. The encrypted password = MD5(my_user_password
+
MD5_MESH_STRING). The client have to return something like this:
> PASS MD5(my_user_password +
MD5_MESH_STRING)
If the password is not correct the FS returns
< PASS NOK
<o> close connection
else
3. Deciding which server is most convinient for the client.
The server gets the Contact List for the user. The contact list
contains users, groups and which user in which group is situated. Every
user in contact list has XBIT which can be -1, 0, 1, 2 - awaiting
authorization, visible, invisible, ignore list. This information is
added as user_in_group information. For example if user X is in groups
120,130,45,0 that means that the user belongs to groups with ids -
120,130,45 and also this user is can see my presence status.
After the contact list, the FS tries to figure out which Message
Server(MS) is most convinient to server the client and the system.
Some criterias for choosing most convinient MS server:
- it is UP, and isn't overloded with people
- most ot the users in the contact list for this client are in MS
server X. Local messages are faster then relayed messages.
- #ToDo:: add additional criterias
The desicion making process should be quite fast.
After the desicion is taken the FS sends to MessageServer (MS) X
FS > SRV_ADD_CREDENTIALS
my_user_id
sceenname contact_list_str protocol client_name UNIQUE_CREDENTIALS
If the server responds with
MSX < SRV_ADD_CREDENTIALS
my_user_id OK
then the MSX server writes down the information in the
IM_USER_CREDENTIALS table and the FS writes down the information about
the user in its IM_USER_IN_SERVER table.
4. Redirecting the client to Message Server
After that it responds to the client with
> GOTO MessageServerX:Port
UNIQUE_CREDENTIALS
<o> close connection
or sends error message. If there was no error then the client have to
connect to the new MS server with the UNIQUE_CREDENTIALS
2. Login to Message Server
1. Showing credentials to MS server
The client tries to connect to MS server using the adress and port of
the MS server. When the client is connected it send:
> USER my_user_id MAGIC_COOKIE
The MS server checks if there is valid(if the client tried to
connect within 60 secs after the client credentials were saved)
MAGIC_COOKIE record for my_user_id in its database.
On invalid request the MS server sends back:
< USER my_user_id NOK
<o> close connection
otherwise the server sends back to
client
< USER my_user_id OK
The MS server send to FS server reply that the my_user_id has
logged in it.
MS > SRV_USER_STAT my_user_id LOGGED
And the front server updates it records and sets the client status to
LOGGED/Before that it was LOGGING/
FS < SRV_USER_STAT my_user_id OK
2. Getting contact list from MS server
The next thing that the client has to do is to get the contact list.
the command to do this is
> GCL LOCAL_CONTACT_LIST_ID
The server compares LOCAL_CONTACT_LIST_ID with the contact_list stored
in the server and if they don't differ MS sends back
< GCL LOCAL_CONTACT_LIST_ID OK
else the server sends back
< GCL NEW_CONTACT_LIST_ID
ITEMS_TO_FOLLOW ENCODING
The encoding is the charset in which the items in the contact
list are writen. ITEMS_TO_FOLLOW is the total number of users + groups.
After this command the MS server sends info about the groups and users.
The GROUP_NAME and USER_NAME are URL encoded.
< CLG GROUP_ID GROU_NAME
Example: < CGL Test+Group
345
And the users are described with this command:
< CLU USER_NAME USER_ID GROUP_ID_1,GROUP_ID_2, ... ,GROUP_ID_X
The list of groups in which the user is included are separated by ",".
If you want to say/express that user is in your invisible list add to
the list ot groups the ID of special group 1.
Special groups "-1" - Awaiting Authorization
0 - Visible
1 InVisible
2 Ignore
3. Getting Presence information for the users in the contact List
When the client receives all items in his/her contact list he/she has
to become ONLINE. This is done by sending this command to the MS server:
> STAT ONL
Valid statuses are:ONL(online), OFF(offline),IDL(idle),BSY(busy),
HDN(hidden)
The MS server tries to send this notification to all online users in
the client contact list. The MS server asks the FS for the address of
the servers, serving the users in the contact list. The MS tries to see
if there is local record for user X server by Y and if there is no such
record it adds USER_ID_X to the list of users.
MS > SRV_WHEREIS_USER
USER_ID_1,USER_ID_2,...,USER_ID_N
FS read the information in its database. After that it sends
addresses of the servers for each user in the list.
FS > SRV_USER_SERVED_BY
USER_ID_1,USER_ID2,...,USER_ID_N server1:port1,server:port,...
If user is not logged it send 0 as corresponding server
parameter.
MS asks every server for the status of the clients they are serving,
that are online and are in his/her contact list
MS > SRV_GET_USER_STAT user_id_1
MS1 responds with
MS1 < SRV_SET_USER_STAT user_id ONL
And MS writes down the status in the local tables + sends to the client
> STAT user_id_1 ONL
4. Remembering which user by which server is served
The MS server writes locally information about the users and servers
that serve them.
5. Send initial presence status
After that the MS server can determine which user in the contact list
is online. Therefore it resends to every online(not in the invisible,
ignore, or awaiting authorization list) user (to the other
MessageServer (MS2) in fact) this message.
MS > SRV_USR_MSG user_id_1
STAT my_user_id ONL
The MS2 redirect locally this message to user with id user_id_1
6. Messages
When the client tries to send instant message it sends something like
this to the MS server
> MSG TYPE ENCODING TO_USER_ID
LENGTH MESSAGE_CONTENT
Example: MSG text utf8
galfy@bgdate 10 1234567890
The MS server checks if TO_USER_ID
is local user for this server
If TO_USER_ID is local user MS
writes down the message in the IM_EVENT
table
else if the TO_USER_ID has
record in the USER_LOCATION
table MS server sends to the other MS server:
MS > SRV_USR_MSG TO_USER_ID MSG text utf8 my_user_id 10 1234567890
And the other MS server saves it in its IM_EVENT table. The thread that is
serving our client gets this message, check if the FROM_USER_ID is not
in ignore list, and send it to the client
If the operation is successful the MS returns
< MSG OK
Otherwise it returns
< MSG NOK
7. Adding new user to contact list
8. Adding new group to contact list
9. Changing user name and groups he/she takes part in
10. Changing group name
11. Moving user in different group
12. Deleting user from contact list
13. Deleting group from contact list
14. Searching for user to
add
15. ..
16. Disconnecting
if disconnection event occures - either the client sends
> QUIT
or the connection MS - Client is broken
or FS disconnects client with some reason
FS > SRV_QUIT my_user_is REASON_CODE
1. The MS server deletes his local records with credentials
2. The MS server send to every MS server, that is serving online
users from his/her contact list:
MS > SRV_USR_MSG user_id_1
STAT my_user_id ONL
3. .. And then MS sends
MS > SRV_USR_DISCONNECTED
my_user_id
4. And the other MS server deletes his record in the local
USER_LOCATION table
5. And finally MS sends to FS
MS > SRV_USER_DISCONNECTED
my_user_id