the JOIN command. This will bypass invite-only mode as well for
the client who got the founder mode during JOIN.
- o After backup resume protocol the TOPIC_SET was not handled correctly
- by all (unknown Channel ID).
+ o Optimize the WHOIS and IDENTIFY commands to check if the request
+ includes an ID or multiple IDs, then they are checked from local cache
+ first, and not sent directly to router. This is because if they
+ are found in the local cache there's no need to send them to the
+ router. Only if some ID is not found, or an found entry is
+ incomplete it can be queried from the router. This way these
+ commands become faster, and for example JOIN command becomes a lot
+ faster since the server ends up resolving the same information only
+ once, as opposed to resolve it everytime JOIN command is issued, like
+ it does now.
+
+ The same thing can be done with WHOWAS command as well.
+
+ It is important to send these requests to router only if they can be
+ expanded to many results (as when doing WHOIS for nickname). If
+ they are explicit (like requesting by ID) the local cache MUST be
+ searched before sending it to router.
- o Channel user mode changes are notified unnecessarely when switching
- to backup router on router crash.
+ o Announcements are incomplete: channel topics are not announced,
+ user modes (UMODE) are not announced.
o Change the server to connect to another server from low ports (706)
and not from high ports. Currently we cannot do incoming connection
checking by remote port because the port is not fixed.
- o Announcements are incomplete: channel topics are not announced,
- user modes (UMODE) are not announced.
+ o Backup router related issues
+
+ o After backup resume protocol the TOPIC_SET was not handled
+ correctly by all (unknown Channel ID).
+
+ o Channel user mode changes are notified unnecessarely when
+ switching to backup router on router crash.
o If client's public key is saved in the server (and doing public key
authentication) then the hostname and the username information could
each JOIN command will create and distribute the new channel key
to everybody on the channel.
- o Optimize the WHOIS and IDENTIFY commands to somehow check whether the
- requested clients are on some channel that the server knows about. If
- this is the case then the request is not needed to be forwarded to the
- router. One specific optimization could be done with JOIN command.
- If the previous command to the WHOIS and IDENTIFY commands are JOIN
- command (from the client) it can be expected (though it must be
- verified) that the client is resolving the users on the channel it just
- joined. If server has done this once there is really no reason to
- resolve it twice (from the router), it can reply directly back with
- the information it knows. This is because the server would (will)
- receive notifications from the router for users that are on a local
- channel.
-
- The same is with whowas command. Actually with all these commands
- it should be checked also whether the requested information is local.
- If it is, there is no reason to send it to the router, since the server
- knows it best.
-
o New configuration file format must be added. The new one will be
done using the dotconf config library (lib/dotconf). The following
tasks relates closely to this as well and must be done at the same time
projects / silc.git / blobdiff