possible to have 2^8 same nicknames from the same
server IP address.
-o MD5 hash - MD5 hash value of the nickname is truncated
- taking 88 bits from the start of the hash value. This
- hash value is used to search the user's Client ID from
- the ID lists.
+o MD5 hash - MD5 hash value of the lowercase nickname is
+ truncated taking 88 bits from the start of the hash value.
+ This hash value is used to search the user's Client ID
+ from the ID lists. Note that the nickname MUST be in
+ lowercase format.
.in 3
Collisions could occur when more than 2^8 clients using same nickname
Client usually sends the commands and server replies by sending a reply
packet to the command. Server MAY also send commands usually to serve
-the original client's request. However, server MUST NOT send commands
-to client and there are some commands that server must not send.
+the original client's request. Usually server cannot send commands to
+clients, however there MAY be commands that allow the server to send
+commands to client. By default servers MAY send commands only to other
+servers and routers.
Note that the command reply is usually sent only after client has sent
the command request but server is allowed to send command reply packet
-to client even if client has not requested the command. Client MAY,
+to client even if client has not requested the command. Client MAY
choose to ignore the command reply.
It is expected that some of the commands may be miss-used by clients
The header in the packet MUST NOT change during the routing of the
packet. The original sender, for example client, assembles the packet
and the packet header and server or router between the sender and the
-receiver MUST NOT change the packet header.
+receiver MUST NOT change the packet header. Note however, that some
+packets such as commands may resent by a server to serve the client's
+original command. In this case the command packet send by the server
+includes the server's IDs.
Note that the packet and the packet header may be encrypted with
different keys. For example, packets to channels are encrypted with
client to its router (or if the server is router, to all routers in
the SILC network). More information about this in [SILC2].
+Router server MUST also check whether some client in the local cell
+is watching for the nickname this new client has, and send the
+SILC_NOTIFY_TYPE_WATCH to the watcher.
+
.ti 0
4.2 Creating Server Connection
it should have cached the Client ID from the SILC Packet Header.
If server receives a private message packet which includes invalid
-destionation Client ID the server MUST send SILC_COMMAND_IDENTIFY
-command reply packet destined to the client with error status.
+destionation Client ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+notify to the client with error status indicating that such Client ID
+does not exist.
See [SILC2] for description of private message encryption and decryption
process.
in [SILC3], however, the HMAC key material MUST be discarded.
If the key is pre-shared-key or randomly generated the implementations
-should use the SILC protocol's mandatory cipher as the cipher. If the
-SKE was used to negotiate key material the cipher was negotiated as well.
+SHOULD use the SILC protocol's mandatory cipher as the cipher. If the
+SKE was used to negotiate key material the cipher was negotiated as well,
+and may be different from default cipher.
+
.ti 0
4.7 Channel Message Sending and Reception
distribute the message to all clients on the channel by sending the
channel message destined explicitly to a client on the channel.
-See the [SILC2] for description of channel messege routing for router
-servers.
+If server receives a channel message packet which includes invalid
+destionation Channel ID the server MUST send SILC_NOTIFY_TYPE_ERROR
+notify to the sender with error status indicating that such Channel ID
+does not exist.
-See [SILC2] for description of channel message encryption and decryption
-process.
+See the [SILC2] for description of channel messege routing for router
+servers, and channel message encryption and decryption process.
.ti 0
Client usually sends the commands in the SILC network. In this case
the client simply sends the command packet to server and the server
-processes it and replies with command reply packet.
+processes it and replies with command reply packet. See the [SILC3]
+for detailed description of all commands.
However, if the server is not able to process the command, it is sent
to the server's router. This is case for example with commands such
local clients that are joined on the same channels with the remote
server's or router's clients.
+Router server MUST also check whether some client in the local cell
+is watching for the nickname this client has, and send the
+SILC_NOTIFY_TYPE_WATCH to the watcher, unless the client which left
+the network has the SILC_UMODE_REJECT_WATCHING user mode set.
+
.ti 0
4.11 Detaching and Resuming a Session
projects / silc.git / blobdiff