Sounds like a good idea to me. No objections here.
My only qualm is whether we are increasing the likelihood of network overload or unwanted interactions between different systems by having lots of devices on this network.
System Software Design
Re: System Software Design
I don't think so.
First, none of the devices will be heavy network users; even the River System Pis only exchange small amounts of data every 30s or so on average. Second, most of the additional Pis won't be network users at all, except during updating or minor config changes. Thirdly, we have a lot of Switches in the network, so traffic will largely be confined to those network segments that are needed to route the info at any given time. We would have to consider any future proposals for expansion with data throughput impact in mind of course.
Compared to a Corporate network, (or even a home network with several entertainment devices), I would imagine that this will continue to be a very lightly loaded network indeed.
First, none of the devices will be heavy network users; even the River System Pis only exchange small amounts of data every 30s or so on average. Second, most of the additional Pis won't be network users at all, except during updating or minor config changes. Thirdly, we have a lot of Switches in the network, so traffic will largely be confined to those network segments that are needed to route the info at any given time. We would have to consider any future proposals for expansion with data throughput impact in mind of course.
Compared to a Corporate network, (or even a home network with several entertainment devices), I would imagine that this will continue to be a very lightly loaded network indeed.
Terry
Re: System Software Design
I think you are right on the money Terry, the only think I would caution is that the re-named River System network and all that goes with it needs to have a separate existence from anything that the WMT business side may do in the future ... and no I don't know what that might be right now but I'd want to make sure we didn't run into any issues to do with personnel records, financial transactions and that sort of IY management nightmare.
Re: System Software Design
Penri,
I don't envisage the new expanded network being any different from the current River System Network; it will just have more hosts.
The main reason that I proposed this was because I'm beginning to allocate IP addresses for devices that are clearly not part of the River System and we clearly need a central place to record these.
I'll create the new Forum and propose a draft architecture, etc tomorrow.
I don't envisage the new expanded network being any different from the current River System Network; it will just have more hosts.
The main reason that I proposed this was because I'm beginning to allocate IP addresses for devices that are clearly not part of the River System and we clearly need a central place to record these.
I'll create the new Forum and propose a draft architecture, etc tomorrow.
Terry
Re: System Software Design
I have raised the new Forum atviewtopic.php?f=41&t=263.
Please follow that link as I have a question.
Please follow that link as I have a question.
Terry
Re: System Software Design
Should it be noted that Patrick and I have mostly been following the paradigm of defensive programming (ensuring at multiple stages that preconditions are met and the set up is valid) rather than design by contract (not checking the preconditions, as the invoker that calls a given method has the task of ensuring they are met first).
In more plain language, we have gone the route of:
- Throwing and catching exceptions/errors when invalid operations (function/method calls) or states are requested.
- Additionally, doing checks to try and ensure these exceptions/errors never need to be thrown.
Instead of:
- Not checking preconditions in the called function/method, resulting in undefined behaviour when preconditions to those functions or methods aren't met.
- The idea with this (design by contract) is that the caller has the responsibility of checking the preconditions.
We both chose this (defensive programming) as it is less likely to result in errors, at the expense of some speed as there is duplicate checking of eg method arguments. As this system doesn't need to be fast (and CPU load is low), I think our current approach is best and probably doesn't need to be changed.
However, I think this should be documented so whoever maintains this system next is aware of our choices.
Thoughts?
In more plain language, we have gone the route of:
- Throwing and catching exceptions/errors when invalid operations (function/method calls) or states are requested.
- Additionally, doing checks to try and ensure these exceptions/errors never need to be thrown.
Instead of:
- Not checking preconditions in the called function/method, resulting in undefined behaviour when preconditions to those functions or methods aren't met.
- The idea with this (design by contract) is that the caller has the responsibility of checking the preconditions.
We both chose this (defensive programming) as it is less likely to result in errors, at the expense of some speed as there is duplicate checking of eg method arguments. As this system doesn't need to be fast (and CPU load is low), I think our current approach is best and probably doesn't need to be changed.
However, I think this should be documented so whoever maintains this system next is aware of our choices.
Thoughts?
Hamish
Re: System Software Design
I agree that it should documented. Where would be the best place for it?
Terry
Re: System Software Design
How about we insert a new small section, 3.2, called Defensive Design, (between our existing 3.1 and 3.2) into the software design document at https://wmtprojectsforum.altervista.org ... ss_0.9.odt?
It could essentially copy and paste what I said above, so we include the reason we chose defensive programming over design by contract as well as that we chose it.
It could essentially copy and paste what I said above, so we include the reason we chose defensive programming over design by contract as well as that we chose it.
Hamish