|Perl Monk, Perl Meditation|
Interprocess messaging with Net::Clacksby cavac (Parson)
|on Oct 04, 2018 at 11:52 UTC||Need Help??|
So, your project is going fine, your codebase is groing fast. But now your have the problem that some of your processes have to communicate with each other. Maybe, some temperature sensor needs to report its sensor value every few seconds to the central heating system. Maybe the central heating system needs to know if the windows are open and close them before heating the house. Another process wants to count how many times the door has been opened and log the sum once a minute...
Net::Clacks to the rescue!
The Net::Clacks modules implement a client/server based interprocess messaging. Without going too much into the internals of the protocol, a client can either send notifications ("event xy has just happened") or values ("the reading for sensor xy is now 42"). Other clients may (or may not) choose to listen to those broadcasts.
Net::Clacks also implements Memcached-like value storage and retrieval. So instead of broadcasting, a value can be stored, read out, incremented, decremented and deleted.
A note on security: Currently, the system only implements a shared-secret type thing (all clients in a clacks network use the same username/password). This will get changed in the future. I'm planning to make it so that you can override the authentication checks with your own function and return which permissions the client has. But that is not yet implemented.
Let's do a simple example project: Server, chatclient, chatbot and a clock process to trigger some actions at the start of every minute.
First of all, we need a server. For this, we need an XML config file and a bit of Perl code.
And the config (saved as clacks_master.xml, we'll add a slaveserver later on):
Oh, and yes, we need an OpenSSL certificate as well. For this demo we will make a self signed one. Not very secure, but sufficient for a proof of concept:
Now let's start the server:
First client will be the "clock.pl" process, this is basically a "write only" thing, it only sends a notify() to all clients listening to it at the start of every minute.
Notice, we also have to send the occasional ping(). This tells the server we are still alive, so it doesn't close the connection. You usually do this in your main loop. I personally had a bug in which the client kept sending some data while it was stuck in a subroutine, so this is some sort of insurance that the clients higher brain functions still get called...
Another thing to note is the doNetwork() call. Message sending and receiving over the network doesn't happen automatically, messages get buffered in the client library. This reduces network traffic when handling lots of small messages by bundling them into bigger packets.
Now, let's do the actual chat client. This is quite similar, except we listen() to some messages at the beginning and also handle the extra message types. Oh, and of course, take line-by-line user input and send those chat messages to the server.
At the beginning, we listen() to the two message names. On user input, we send it as a chat message to everyone else listening to the chat. Roughly every 60 seconds we ping() the server (keepalive again). Then we send and receive with doNetwork() and check to see if we got any interesting messages.
We could simplify the checks quite a bit since there are only two well defined messages (one 'notify', one 'set'), but i implemented the full checking here to illustrate the principle.
Last but not least, let's implement the most brain-dead chatbot we can think of. It repeats messages containing "simon" with "Simon says". It also implements a counter in Clacks for counting chat messages. Every time it gets a clock notification, it sends the number of chat messages seen since the last notification as a chat message and decreases the counter accordingly. (I could just set it to zero, but using decrement with the previously read out value is the correct thing to do, especially in cases where the counter is increased by some other program).
Ok, sure, this chat system will never get much users, because it just doesn't have good features. It's just a demo of some of the Net::Clacks capabilities.
But "what if" you actually get more users or processes that a single service or server can handle? No problem here, either. Net::Clacks::Server has what is called an "Interclacks" mode, which can be used to run in master/slave mode. When a slave starts up and connects (or reconnects after a network error) to the master, it drops it's locally stored variables and resyncs from the master.
After that, every message or stored variable you set/send/notify gets automatically synced to the master. A slave can also work as a master node at the same time, so you are able to chain nodes in a tree like pattern if you really so desire.
So, lets make a slave node. In our case, it will run on the same host with a different port (but you can trivially change it to run on a different server). All we need is an additional XML config file:
And then start it:
So far, i have had Net::Clacks in use on a couple of live systems for over 2 years, most of them running 1000+ clacks connections at the same time. At least one of them having a constant 24/7 message rate of roughly 5000 messages per minute. Pretty much no crashes in the last few months. Obviously, you need to test, test, test before you decide to use it for your own systems.
"For me, programming in Perl is like my cooking. The result may not always taste nice, but it's quick, painless and it get's food on the table."