Yes, that's the Sockets object (Tools/sockettools.py), along with the SocketHandlerThread object that gets created for each end of each socket.I think each message would need to consist of:
Presumably there will be an object that handles sending and receiving messages, which gets initialised on each Pi, taking the address of the 'message broker' from the config file?
- a site ID to send the message to,
- something to say that it's a reading interval request (in case we ever want to send other kinds of messages), and
- the requested interval itself.
This seems like a reasonable way to do things.Then, in the main loop, after the control algorithm executes, main.py identify the minimum interval among:
The local interval can then be set to that minimum.
- any incoming messages that were sent to the local site ID from the other Pis
- a default interval and
- any requests that the collector gathered for the local site ID.
Does that seem in line with your expectations?
Yes, I was thinking of using the SocketHandlerThread class to manage this, and hide the complexity from the main loop. Then, as you say, any pi/other device running the sockets code could then be a message broker/forwarder. This would also stop the main loops from being able to "snoop" on messages being delivered to other connected devices, but that aren't intended for the current device.Or, perhaps it works out neater to have a special 'message broker' kind of object that handles the send/receive on the NAS, and which contains the logic for "routing" them to the right destination, so it's a case of repeatedly calling some "routeMessages" method on the object, and that method does all the work.
It might also be sensible to run all the NAS-side message broking in its own thread, rather than in the main loop. That way, if we were ever to decide that, actually, one of the Pis should be the message broker it could take on the dual roles of broker and client? The message broking thread would have no need to communicate with the rest of the program, except via the network, so I guess there are no or few concerns about concurrent access to shared state? (He says, looking at the concept of threads through narrowed, untrusting eyes.)
The thread programming is a bit tricky and has caused us problems in the past, but Python's Global Interpreter Lock (https://wiki.python.org/moin/GlobalInterpreterLock) helps us a little bit in this case.
Reply to your last message Patrick:
Yes I suppose we don't need a message-bus-type-thing for that, but by the sounds of it, it's something that may well be useful to have later, so I might go ahead and implement it anyway - it really shouldn't be too hard.