I've started to use Python almost exclusively for all development over the last year or so on both Linux and Windows environments, including TCP daemon style apps.
I did try going back to C, but I've been spoilt by C# over the last 7 years and don't really want to live without my garbage collector.
I recently needed to write reasonably complex TCP server and after trying PHP - which is realistically about as close to C that I want to get - I went back to Python, it just feels like a more natural language. Python comes with a decent Socket Server and can be daemonized relatively easily.
As for how to catch those errors and bugs, I'm sure I'm teaching you how to suck eggs, but.... try...catch (or its equivalent) is your friend :-)
Nick.
Occasionally I have the need to write some communications software, typically something that connects to a serial or TCP port, writes requests and reads responses, writing the results into a database.
Usually the basics are simple enough to achieve, but the challenge is in making a robust solution that will cope with lost connections and any other variety of reasons why things might go wrong (including bugs in the script itself).
What is the "best" way to approach something like this? Are some programming languages better than others for this? What's the best way to ensure a script restarts if it fails for some reason?
I'm looking for something Debian/Ubuntu based if relevant.
[Aside: One reason for asking is that I have been playing with an app I downloaded that talks to CurrentCost power meters, with a PHP-based web interface and a Python-based daemon, and I'm not sure why Python was chosen for it; also I note that the daemon regularly crashes on my system leaving me without any data.]
--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450
Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
_______________________________________________
main@lists.alug.org.uk
http://www.alug.org.uk/
http://lists.alug.org.uk/mailman/listinfo/main
Unsubscribe? See message headers or the web site above!