

-------------------------------------------------------------------------------


General                 Project SMSLink - Known bugs and Todo list
Introduction
Documentation
Platforms               Table of Contents
Supported_Hardware
Package_Content
                        * Known_bugs.

Installation              o Server.
Download                  o Client.
Server_Install            o Gateway.
Client_Install
Gateway_Install         * Todo_list.
Upgrade
                          o Server.
                          o Client.
Tech Info                 o Gateway.
Changelog
FAQ
Drivers                 Please be aware that in the following lists, the order
PDU_format              in which the items are presented doesn't represent any
Bugs_/_Todo             idea of relative severity (bugs) or priority (todo
Related_Links           items). All those items are just listed, as they say,
                        "in no particular order".
                        -------------------------------------------------------
_Jump_to_Vim_Home_Page_
                        Known bugs


                        Server bugs


                        * (01/09/98) When the parser experience a "parse error"
                          (typing mistake, command not recognized by the
                          grammar), an error message is generated all right,
                          but the next command(s) to be issued, correct or not,
                          won't be processed. You first have to press [return]
                          a few times (as many times as there are words in the
                          first, incorrect command line) to "purge the buffer"
                          that's still holding this line.
                          Specially for the "set" command, the input buffer
                          size defined by default by lex doesn't seem to be
                          quite enough. When a very long string is keyed in, a
                          "parse error" will be generated, due to the fact that
                          the closing quote won't be seen by the parser. You
                          then have to press [return] quite a few times to
                          purge the buffer (see previous bug).
                          Some side effect here is the fact that if the
                          original string contained a sequence of words
                          meaningfull to the language, they might get executed.
                          Solved in 0.56b.
                        * (02/09/98) The interactive interface (command prompt)
                          is not displayed correctly when accessed from a DOS/
                          Windows machine. To display the strings correctly, I
                          had to replace '\n' char. by "\r\n". This fix doesn't
                          seem to affect the Unix clients (using standard
                          telnet) in the least.
                          But even then, a "parse error" is generated for each
                          character that the DOS/ Windows client is sending
                          (even though the yytext string seems to contain only
                          that character).
                          UPDATE: the telnet client have to implement "line
                          mode", not "character mode". I was able to configure
                          Reflection ver. 6 (32bit) to do so (see varia
                          directory, a file called SMS.R1W). But neither the
                          telnet applet that ships with Win95 or WinNT, nor
                          older versions of Reflection seem able to support
                          that. So it would be much better to handle this on
                          the server side.
                        * (17/05/01) The way it is implemented now, the
                          "dedicated daemon" code does not follow the same
                          strict policy for access to the shared memory segment
                          we used in the other parts of the code (use of
                          critical sections protected by semaphores).
                          Due to the fact that the devices affected by the "dd"
                          flag are reserved for use by that code anyway, we
                          don't believe that this violation should lead to
                          serious troubles (the only other place where that
                          part of the shared memory segment might be accessed
                          is through commands such as "dl" or "stats" in the
                          interactive interface - and then only in R/O mode).
                          Still, good coding practices would prompt us to
                          improve this.
                          (25/09/01) This might explain the error message
                          relative to the shared memory segment when stopping a
                          server running in "dd" mode.
                        * (25/09/01) The server in "dd" mode, when sending,
                          doesn't report the message ID the way the "regular"
                          server does. This prevents the new reporting feature
                          of the client (sendsms >= 0.18b) from working against
                          a server in "dd" mode.
                        * (30/07/03) When in "dd" mode, the server will only
                          support the send command.


                        Client bugs


                        * (12/11/98) There seems to be a problem with the
                          client when installed on a 1.2.13 Linux box (old
                          SlackWare install). The commands are delivered all
                          right to the server, but the client exits (times out)
                          before a positive acknowledgement could be received.
                          It returns thus a message to the effect that the
                          message could not be sent, although it was sent
                          successfully.
                          I didn't try to increase the timeout value, but since
                          it represents a number of seconds, it should behave
                          the same no matter what the kernel revision.
                          (25/09/01) This problem might be solved by version
                          0.18b of the client, and the new way it implements
                          the dialogue with the server. I haven't had the
                          ability to test that yet.


                        Gateway bugs

                        (momentarily empty).
                        -------------------------------------------------------

                        Todo list


                        Server Todo list


                        * Clean code (add tests after each malloc() call if not
                          the case yet).
                        * Improve Makefiles. Integrate them in an automake/
                          autoconf environment.
                        * Might be needed to add "routing help" for specific
                          routes (i.e., how can we build a solution that would
                          allow us to deliver SMS straight to GSM networks that
                          are not normally reachable from the regular
                          provider). More on this after some testing.
                        * Solve this "char" versus "line" mode problem in
                          telnet.
                        * Improve the procedure that will save the incoming
                          messages to file. Currently, messages might get lost
                          in the following scenario: if the mailbox file is
                          locked (by another application) when the server tries
                          to save the messages, an error is issued but the
                          server doesn't retry, it just goes on and happily
                          removes the messages from the SIM, meaning they're
                          just lost.
                        * Improve parsing (we should use a separate procedure
                          to get the commands, then parse them one at a time)
                        * Improve variable handling (and typing) in the parser.
                        * Add "validity period" handling for the SMS messages.
                          There should be a configurable application-wide
                          default value, and a command supported by the parser
                          for the user to override this default.
                        * Add support for "Flash SMS" (those that appear on the
                          handy display without you having to press any key to
                          select them).
                        * Add command line parameters handling in the server 
                          (listening port, interval between incoming messages
                          checks, ...). Work in progress: this is partially
                          implemented in 0.54b, and will be more thoroughly in
                          upcoming 0.55b. Implemented in 0.55b.
                        * Integrate MySQL patch. Work in progress: will be
                          available in upcoming 0.55b. Implemented in 0.55b.
                        * Add queuing mechanism in addition to immediate
                          delivery. Provide possibility for immediate mode to
                          either fail and return an error code or be queued
                          instead. Work in progress: this will be partially
                          implemented in upcoming 0.55b. Implemented in 0.55b.
                        * Add a "load" command to send pre-formatted PDU
                          strings.
                        * Add support for logos and ringtones handling.
                        * Add a "long" parameter to the "devicelist" command,
                          that will display all the properties attached to each
                          module, including a list of its option flags.
                          Implemented in 0.55b.
                        * Add the appropriate commands for the administrator to
                          interactively add or remove an option flag from a
                          module without having to stop and restart the server.
                        * Integrate the mail2sms perl script provided by Stan.
                          Devise an install procedure and document it.
                        * Review code for security risks. Try to make server
                          drop root priviledges when they're not needed
                          anymore.
                        * Add support for SNPP protocol in both client and
                          server (while still keeping the "interactive"
                          interface as it is now). We could have the server
                          listening on 2 separate ports: one meant for client
                          programs and parsing SNPP requests, and the other
                          meant for administrators only, for maintenance or
                          debugging. I could also build a separate snppd
                          daemon, that would just accept and queue messages.
                          sms_serv(1) would pick those messages up and send
                          them. Might be the easiest route.
                        * When increasing the capabilities of the "interactive"
                          interface, it might become usefull to include some
                          form of authentication, at least when accessing the
                          more sensitive features of that interface.
                        * Add a configuration file (global to both server
                          modules) to ease the handling of more options to
                          come.
                        * Add an "enable" mode to sms_serv interactive
                          interface ("enable" in the sense that Cisco IOS gives
                          it), allowing for some data / actions to be
                          restricted to the administrator.


                        Client Todo list


                        * Clean code (add tests after each malloc() call if not
                          the case yet).
                        * Improve Makefiles.
                        * Add parameter to override default port for service.
                          Modify algorithm used to get it. If value provided as
                          parameter, use that. Otherwise, try to get it through
                          getservbyname(), and only when that fails use the
                          compiled-in default value. Implemented in 0.18b.
                        * Improve error reporting by providing some analysis of
                          the error code returned by the module (the +CMS
                          ERROR, for instance).
                        * Try to improve performance (regarding this long
                          timeout). Implement the same approach used for "fast
                          modem response" in the server. Implemented in 0.18b.
                          If desirable, control that behaviour through a
                          command-line option. Not needed any more (notion of
                          "fast" vs. "slow" mode dropped on the client side).
                        * Build a GUI-based client for Linux.


                        Gateway Todo list


                        * The gateway process currently supports only the inbox
                          file as a message store. Since the server now also
                          supports a back-end database, it would make sense to
                          expand the gateway in order for it to be able to also
                          retrieve incoming messages to process from the DB
                          inbox table.
                        * When processing the inbox file, the gateway process
                          currently dies when it encounters some invalid inbox
                          entry (any line it can't parse). It would be much
                          more efficient to then remove the offending line and
                          store it in a "rejects" file (in the same directory
                          as the inbox file). This would allow for easier debug
                          and analysis, or for "salvage" by the administrator.


-------------------------------------------------------------------------------

Last Modified: September 29th, 2006.
     _philipa_STRUDEL_scarlet           _SourceForge_Logo_
     PUNKT_be_

