It is expected that some of the commands may be miss-used by clients
resulting various problems on the server side. Every implementation
should assure that commands may not be executed more than once, say,
-in two (2) seconds. This should be sufficient to prevent the miss-use
-of commands.
+in two (2) seconds. However, to keep response rate up, allowing for
+example five (5) commands before limiting is allowed. It is recommended
+that commands such as SILC_COMMAND_NICK, SILC_COMMAND_JOIN and
+SILC_COMMAND_LEAVE should be limited in all cases as they require
+heavy operations. This should be sufficient to prevent the miss-use of
+commands.
SILC commands are described in section 5 SILC Commands.
If the authentication method is password based, the Authentication
Data field includes the plaintext password. It is safe to send
-plaintext password since the entire payload is encrypted.
+plaintext password since the entire payload is encrypted. In this
+case the Public Data Lenght is set to zero (0).
If the authentication method is public key based (or certificate)
the Authentication Data is computed as follows:
Additional public key algorithms may be defined to be used in SILC.
-.ti0
+.ti 0
3.10.3 Hash Functions
Hash functions are used as part of MAC algorithms defined in the next
network. This is done by broadcasting the SILC_NOTIFY_TYPE_JOIN notify
type to the router's primary route.
-After joining the client to the channel server or router must send
-command reply packet for SILC_COMMAND_USERS command. This way the
-client gets the list of users on the channel. If the router joined
-the client to the channel then the router sends this command reply
-to the server which must send it further to the original client.
-
It is important to note that new channel key is created always when
new client joins to channel, whether the channel has existed previously
or not. This way the new client on the channel is not able to decrypt
Reply messages to the command:
- Max Arguments: 3
- Arguments: (1) <Status Payload> (2) <nickname>[@<server>]
- (3) <username@host>
+ Max Arguments: 5
+ Arguments: (1) <Status Payload> (2) <Client ID>
+ (3) <nickname>[@<server>] (4) <username@host>
+ (5) [<real name>]
This command may reply with several command reply messages to form
a list of results. In this case the status payload will include
Reply messages to the command:
- Max Arguments: 10
- Arguments: (1) <Status Payload> (2) <channel>
- (3) <Channel ID> (4) <channel mode mask>
- (5) <created> (6) <Channel Key Payload>
- (7) [<ban mask>] (8) [<invite list>]
- (9) [<topic>] (10) [<hmac>]
+ Max Arguments: 14
+ Arguments: (1) <Status Payload> (2) <channel>
+ (3) <Channel ID> (4) <Client ID>
+ (5) <channel mode mask> (6) <created>
+ (7) <Channel Key Payload> (8) [<ban mask>]
+ (9) [<invite list>] (10) [<topic>]
+ (11) [<hmac>] (12) <list count>
+ (13) <Client ID list> (14) <client mode list>
This command replies with the channel name requested by the
client, channel ID of the channel and topic of the channel
- if it exists. It also replies with the channel mode mask
+ if it exists. The <Client ID> is the Client ID which was joined
+ to the channel. It also replies with the channel mode mask
which tells all the modes set on the channel. If the
channel is created the mode mask is zero (0). If ban mask
and/or invite list is set they are sent as well.
+ The <list count>, <Client ID list> and <client mode list> are
+ the clients curerntly on the channel and their modes on the
+ channel.
+
Client receives the channel key in the reply message as well
inside <Channel Key Payload>.
projects / silc.git / blobdiff