SMSLink 0.56b-3

SMSLink project implements a client/server gateway to the SMS protocol (short messages on the mobile phones).
It requires the use of dedicated hardware (a serial GSM module).
Both SMS emission and reception are supported, either in text-mode or in PDU-mode.
It also includes an SMS to eMail gateway module.
The server runs under Linux and FreeBSD and supports interactive mode via telnet.
The command-line client already exists for Linux, FreeBSD, Solaris, HP-UX, and Win32.
A basic Web interface is also provided.
Main features:
- The use of TCP/IP sockets for communication between client and server means that the application is network-aware from the start and that deploying it over a WAN (or across the internet) is a piece of cake. Expanding it as well, since writing additional clients for it is possible on any platform supporting sockets. Various ports of the client to Win32 are now available.
- The server process has a command-line interface connected to the socket, making it possible to use it interactively from a telnet session (only line mode telnet supported at the present time - see server/BUGS and server/TODO in the sources directory). This feature is of enormous help when troubleshooting or debugging.
- The command-line interface is backed by a parser written in lex and yacc (flex/bison, actually), which makes the language relatively easy to extend.
- The server was built from the start with the idea of multiple GSM modules in mind. Adding a line to two configuration files (and connecting the hardware, of course) is all there is to using two modules instead of one. The number of modules supported by the server is limited by the hardware only.
- The choice to use specific hardware (the serial GSM module), although limiting the general-purpose use of this application, allows for some very usefull features, the most prominant one being the ability to receive SMS messages as well as send them. This feature is now implemented (as of version 0.41b). Once downloaded from the GSM module, those messages can either be stored in an inbox file or fed through an external program or script, or both.
- By sitting straight on the GSM network, the use of the GSM module offers an advantage that far outweighs its cost : provider independance. The ability to send and receive SMS might be limited in some way or another by the level of your subscription, but all providers should offer a standard way of doing it. No "provider-specific driver" is required in this case. Whats more, all SMS routing aspects are being taken care of by the GSM network itself. Caution is advisable when choosing the provider though, as some of them might place some restrictions on routing to and/or from outside networks (e.g. Mobistar and Itineris*) or lack the implementation of some advanced features of the SMS protocol such as "point-to-point SMS" or "SMS-back" (e.g. Proximus through the UCP interface*).
- As of version 0.48b, initial support for PDU mode and the creation of a "driver-like" capability table for the GSM modules means that most module brands on the market could be supported with little effort. This "driver" approach also garanties that youll be able to mix and match different brands and models of modules on the same server with no problem. Support for PDU mode also opens up a new batch of options, like setting the validity period for a message, potential support for non-standard alphabet, binary content delivery to the mobile phone (logos, tunes, etc. ?) and more.
- A full-fledged access control mechanism allows you to specify precisely which client machine or subnet should be allowed to connect and which shouldnt. The access control is IP-based (as opposed to user-based) and defaults to "deny" for increased security. When the situation doesnt require any access control, the whole thing can be easily disabled by the administrator.