From 334514d6229cf4a8fedbe548d9f7639ceaf4742d Mon Sep 17 00:00:00 2001 From: Pekka Riikonen Date: Sun, 13 Jan 2002 20:40:16 +0000 Subject: [PATCH] updates. --- CREDITS | 18 +++---- TODO | 100 +++++++++++++++++++++++++++++++++------ apps/silcd/packet_send.c | 2 +- apps/silcd/server.c | 2 +- lib/silcmath/mp_mpi.c | 13 +++-- silc_optimize | 81 ------------------------------- 6 files changed, 105 insertions(+), 111 deletions(-) delete mode 100644 silc_optimize diff --git a/CREDITS b/CREDITS index 593cbb12..e070a2f9 100644 --- a/CREDITS +++ b/CREDITS @@ -18,6 +18,15 @@ S: Skinnarilankatu 28 E 2 S: 53850 Lappeenranta S: Finland +N: Johnny Mnemonic +E: johnny@themnemonic.org +W: http://www.themnemonic.org/ +P: 1024D/34E2AB40 9AC6 1460 A5D0 4DB7 70D0 5DA5 C17F 50CD 34E2 AB40 +D: RPM packages +D: silclog, misc bugfixes +S: 35100 Padova +S: Italy + N: Pekka Riikonen E: priikone@silcnet.org E: priikone@ssh.com @@ -28,15 +37,6 @@ S: Snellmanninkatu 34 A 15 S: 70100 Kuopio S: Finland -N: Johnny Mnemonic -E: johnny@themnemonic.org -W: http://www.themnemonic.org/ -P: 1024D/34E2AB40 9AC6 1460 A5D0 4DB7 70D0 5DA5 C17F 50CD 34E2 AB40 -D: RPM packages -D: silclog, misc bugfixes -S: 35100 Padova -S: Italy - N: Juha Räsänen E: jmrasane@lut.fi D: Persistent nagger diff --git a/TODO b/TODO index 2cbfee2e..c2bf5c9e 100644 --- a/TODO +++ b/TODO @@ -103,9 +103,6 @@ TODO/bugs In SILC Server TODO/bugs In SILC Libraries =========================== - o make install copies the symblic links from lib/silcsim/ and not - modules. - o WIN32 silc_net_create_connection_async does not work the same way than on Unix. Do it with threads on WIN32. The function works but is not actually async currently. @@ -175,19 +172,12 @@ describe new stuff to be added to protocol versions 1.x. TODO After 1.0 ============== - o Compression routines are missing. The protocol supports packet - compression thus it must be implemented. SILC Zip API must be - defined. zlib package is already included into the lib dir (in CVS, - not in distribution), but it is not used yet, and it requires some - tweaking on the Makefiles (we want static lib not shared). +A rough list of stuff that is going to be done to SILC after 1.0 or at +least could be done. o Implement the defined SilcDH API. The definition is in lib/silccrypt/silcdh.h. - o Add builtin SOCKS and HTTP Proxy support, well the SOCKS at least. - SILC currently supports SOCKS4 and SOCKS5 but it needs to be compiled - in separately. - o X.509 certificate support. SILC protocol supports certificates and it would be great to have support for them. This is a big task as support has to be made for ASN.1 as well. I've looked into OpenSSL @@ -206,8 +196,90 @@ TODO After 1.0 Other package that should be checked is the NSS's X509 library, which I like more over OpenSSL package. - o SSH2 public keys support. + o SSH2 public keys support, allowing the use of SSH2 public keys in + SILC. - o OpenPGP certificate support. + o OpenPGP certificate support, allowing the use of PGP public keys + in SILC. + + o Compression routines are missing. The protocol supports packet + compression thus it must be implemented. SILC Zip API must be + defined. + + o Rewrite the lib/silcutil/silcprotocol.[ch] not to have [un]register + functions, but to make it context based all the way. The alloc should + take as argument the protocol type and its callback (not only + final callback). It is not good that we have now global list of + registered protocols. + + o Optimizations in Libraries + + o There is currently three (3) allocations per packet in the + silc_packet_receive_process, which is used to process and + dispatch all packets in the packet queue to the parser callback + function. First allocation is for parse_ctx, second for the + SilcPacketContext, and third for packet->buffer where the actual + data is saved. + + The parse_ctx allocation can be removed by adding it as a + structure to the SilcPacketContext. When the SilcPacketContext + is allocated there is space for the parse context already. + + The silc_packet_context_alloc could have a free list of + packet contexts. If free packet context is found from the list + it is returned instead of allocating a new one. The library + could at first allocate them and save them to the free list + until enough contexts for smooth processing exists in the list. + This would remove a big allocation since the structure is + quite big, and even bigger if it would include the parse_ctx. + + The packet->buffer can be optimized too if the SilcBuffer + interface would support free lists as well. Maybe such could + be done in the same way as for SilcPacketContext. The + silc_buffer_alloc would check free list before actually + allocating new memory. Since the packets in the SILC protocol + usually are about the same size (due to padding) it would be + easy to find suitable size buffer from the free list very + quickly. + + These naturally cause the overal memory consumption to grow + but would take away many allocations that can be done several + times in a second. + + o Move the actual file descriptor task callback (the callback that + handles the incoming data, outgoing data etc, that is implemnted + in server and client separately (silc_server_packet_process and + silc_client_packet_proces)) to the low level socket connection + handling routines, and create an interface where the application + can register a callbacks for incoming data, outoing data and EOF + receiving, which the library will call when necessary. This way + we can move the data handling in one place. + + o Add silc_id_str2id to accept the destination buffer as argument + and thus not require any memory allocation. Same will happen + with silc_id_payload_* functions. + + o Optimizations in Server + + o Remove the big switch statement from the function + silc_server_packet_parse_type and replace it with predefined + table of function pointers where each of the slot in table + represents the packet type value. + + Same could be done with notify packets which has big switch + statement too. Same kind of table of notify callbacks could be + done as well. + + o The parser callback in the server will add a timeout task for + all packets. It will require registering and allocating a + new task to the SilcSchedule. Maybe, at least, for server + and router packets the parser would be called immediately + instead of adding it to the scheduler with 0 timeout. It + should be analyzed too how slow the task registering process + actually is, and find out ways to optimize it. o Cipher optimizations (asm, that this) at least for i386 would be nice. + + o Add builtin SOCKS and HTTP Proxy support, well the SOCKS at least. + SILC currently supports SOCKS4 and SOCKS5 but it needs to be compiled + in separately. diff --git a/apps/silcd/packet_send.c b/apps/silcd/packet_send.c index f1b0c9d2..2011c8b3 100644 --- a/apps/silcd/packet_send.c +++ b/apps/silcd/packet_send.c @@ -1704,7 +1704,7 @@ void silc_server_send_channel_key(SilcServer server, unsigned char *chid; uint32 tmp_len; - SILC_LOG_DEBUG(("Start")); + SILC_LOG_DEBUG(("Sending key to channel %s", channel->channel_name)); chid = silc_id_id2str(channel->id, SILC_ID_CHANNEL); if (!chid) diff --git a/apps/silcd/server.c b/apps/silcd/server.c index 55674823..24f71ef5 100644 --- a/apps/silcd/server.c +++ b/apps/silcd/server.c @@ -3020,7 +3020,7 @@ SilcChannelEntry silc_server_save_channel_key(SilcServer server, payload = silc_channel_key_payload_parse(key_payload->data, key_payload->len); if (!payload) { - SILC_LOG_ERROR(("Bad channel key payload, dropped")); + SILC_LOG_ERROR(("Bad channel key payload received, dropped")); channel = NULL; goto out; } diff --git a/lib/silcmath/mp_mpi.c b/lib/silcmath/mp_mpi.c index 56d2730a..513f5591 100644 --- a/lib/silcmath/mp_mpi.c +++ b/lib/silcmath/mp_mpi.c @@ -39,11 +39,14 @@ size_t silc_mp_size(SilcMPInt *mp) size_t silc_mp_sizeinbase(SilcMPInt *mp, int base) { - return mp_radix_size(mp, base) - 2; /* XXX This is actually wrong since - this might produce wrong balue. - But, it looks like MPI always returns - correct value plus one, whereas - GMP returns always the right value. */ + size_t sib = mp_radix_size(mp, base); + if (sib > 2) + sib -= 2; /* XXX This is actually wrong since + this might produce wrong balue. + But, it looks like MPI always returns + correct value plus one, whereas + GMP returns always the right value. */ + return sib; } void silc_mp_set(SilcMPInt *dst, SilcMPInt *src) diff --git a/silc_optimize b/silc_optimize deleted file mode 100644 index 119767b3..00000000 --- a/silc_optimize +++ /dev/null @@ -1,81 +0,0 @@ -SILC Optimizations: -=================== - -o Library - - o There is currently three (3) allocations per packet in the - silc_packet_receive_process, which is used to process and - dispatch all packets in the packet queue to the parser callback - function. First allocation is for parse_ctx, second for the - SilcPacketContext, and third for packet->buffer where the actual - data is saved. - - The parse_ctx allocation can be removed by adding it as a - structure to the SilcPacketContext. When the SilcPacketContext - is allocated there is space for the parse context already. - - The silc_packet_context_alloc should have a free list of - packet contexts. If free packet context is found from the list - it is returned instead of allocating a new one. The library - could at first allocate them and save them to the free list - until enough contexts for smooth processing exists in the list. - This would remove a big allocation since the structure is - quite big, and even bigger if it would include the parse_ctx. - - The packet->buffer can be optimized too if the SilcBuffer - interface would support free lists as well. Maybe such could - be done in the same way as for SilcPacketContext. The - silc_buffer_alloc would check free list before actually - allocating new memory. Since the packets in the SILC protocol - usually are about the same size (due to padding) it would be - easy to find suitable size buffer from the free list very - quickly. - - These naturally cause the overal memory consumption to grow - but would take away many allocations that can be done several - times in a second. - - o Move the actual file descriptor task callback (the callback that - handles the incoming data, outgoing data etc, that is implemnted - in server and client separately (silc_server_packet_process and - silc_client_packet_proces)) to the low level socket connection - handling routines, and create an interface where the application - can register a callbacks for incoming data, outoing data and EOF - receiving and maybe sending too, which the library will call - when necessary. This way we can move the data handling in one - place. - - o Add silc_id_str2id to accept the destination buffer as argument - and thus not require any memory allocation. Same will happen - with silc_id_payload_* functions. - - o Rewrite the lib/silcutil/silcprotocol.[ch] not to have - [un]register functions, but to make it context based all - the way. The alloc should take as argument the protocol - type and its callback (not only final callback). It is not - good that we have now global list of registered protocols. - - -o Server - - o When processing the decrypted and parsed packet we call the - silc_server_packet_parse_type function. This function has a - huge switch statement. Replace this switch statment with pre- - defined table of function pointers where each of the slot - in the table represents the packet type (1 for packet type - value 1, 2 for value 2 and so on), and call the callback - found in the slot. In this case we can do one-to-one mapping - of packet types to correct function. - - o Same optimizations could be done with notify packets which - has huge switch statement too. Same kind of table of notify - callbacks would be very easy to do, and achieve one-to-one - mapping of notify types. - - o The parser callback in the server will add a timeout task for - all packets. It will require registering and allocating a - new task to the SilcSchedule. Maybe, at least, for server - and router packets the parser would be called immediately - instead of adding it to the scheduler with 0 timeout. It - should be analyzed too how slow the task registering process - actually is, and find out ways to optimize it. -- 2.24.0