Mon, 27 Sep 2004
So, I've never spent a lot of time programming network applications. Sure, I've futzed around learning how you go about calling socket(), bind(), listen() and accept() or socket(), and connect(), then doing rudimentary data reads and writes, but I've never really spent the time learning how to make a really robust server daemon that uses non-blocking sockets.. Anyway, to cut a long story short, we've got this little CDMA modem here at work that's been purchased to use as an SMS sending tool, so that we're not relying on some internet service (which work really well when you're trying to send a message to the network admins that the internet connection is broken). This particular modem has no linux software, but it does have a nice AT command set that is available.
So I'm writing a daemon process that can collect messages in a queue, and make sure they're sent, and also collect any incoming messages to deliver them via email if it can work out who should get them.
It's a somewhat satisfying task, involving a large number of general programming tasks like socket, file and device IO, that are in themselves easy, but difficult to do right. All this adds up to a pleasurable learning experience.
I guess I should mention that I have spent a little time looking around trying to find something that can to the job for me, but everything seems to be somewhat bloated, or not general enough to apply to other types of devices. Oh, and there's that obligatory case of NIH syndrome that liw spoke of (OK, a very weak case).
I'm still debating though, whether or not to go down the threads with IPC track, or just create something monolithic with a good dose of careful non-blocking IO.
The latter feels more challenging...
[04:39] [/Hacking] [permanent link]