|
|
Project SMSLink - Known bugs and Todo list
Table of Contents
Please be aware that in the following lists, the order in which the items
are presented doesn't represent any idea of relative severity (bugs) or
priority (todo items). All those items are just listed, as they say, "in
no particular order".
- (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.
- (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.
(momentarily empty).
- 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.
- 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.
- 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.
|
