This post was published 1 year 11 months 10 days ago and as such probably does not reflect my current opinions, knowledge or ability.Unfortunately my honours project is not particularly visual, so it can be hard to update this blog with my progress when I have nothing I can really show. However, progress is being made. The first component of the project, a communications and network library, was completed almost a week ago.
The most useful thing I can share is the class diagram this was based on. It’s rough, it doesn’t detail methods or member data, and it’s far from beautiful, but perfection is an easy trap to fall into. I thought it was better to have a functioning library and an ugly diagram than a work of art demonstrating a library which I then would have no time to create.
The current phase of the project is far more interesting in my opinion, and thankfully should result in something slightly more visually interesting. It concerns the division of the world, hierarchically, into microcells. This spatial partitioning, and more importantly the assignment of work to specific processors is fast becoming the major focus of the project, and I hope to follow up with more on that topic shortly.
EDIT: I have replaced the original diagram with a still-ugly but slightly more descriptive update (if you actually view it at a decent size, that is). The majority of member data and functions are still missing, but hopefully the few I’ve added will make my intentions slightly clearer.
Can you elaborate on what’s what? Are the multiplicity numbers placeholders or actual values? I’ll admit that my UML is a bit rusty, but it looks like a Communicator is composed of one “Receive”, one “Send” (each of which are kinds of Transfer) and one CommsList. I’m not sure what means to have an instance of a Send or Receive. And I’m not sure why a transfer has a listening socket and not a transfer socket. I’m sure it does make sense, but I think I’m missing important clues to decipher the diagram.
I’ve edited the diagram – I forgot that other people might actually try to make sense of what I post! It’s still rough, but hopefully now slightly more meaningful and also more accurate.
The multiplicity values were indeed placeholders.
Basically Comm Reference List stores information about other applications to be communicated with, and a connected TCP socket on which to do so. The Sender and Receiver allow messages to be transferred to and from other components of the application (or to and from the library itself). I hope that makes a little more sense.
Right, I think I understand better now.
I wonder if inheritance is the best relationship between Sender/Receiver and Transfer(rer?). The defining property of Transfer appears to be that it has a message queue, but it seems that this is of no interest to *users* of the class. I think the question to answer when deciding whether two classes should share a common base is not “do these things work similarly?” but rather “do we ever want to treat these things identically without having to care about the concrete type?”. Obviously this opinion is not universal, or C++ would have no need for private inheritance, but I think it’s generally the case that composition is a better choice than inheritance if you’re not going to make use of polymorphism. I would ask the same question with regard to Node Comm and Root Comm, but it’s harder to tell how they will actually be used in practice.
I assume there must still be parts of this diagram missing. In order to do their jobs, don’t Receiver and Sender need to know about either sockets or the Comm Reference List? Or does Communicator do all the work and fill up/flush their queues for them? If that’s the case, I wonder if Communicator is overburdened.
I’m looking forward to seeing the exciting stuff. Am I right in thinking that each of your worker nodes is going to be responsible for simulating some contiguous part of a 2D planar world and communicating with the machines responsible for neighbouring parts of the world?
Sorry it has taken me so long to respond (I needed to complete the area of the project I was working on before looking back at the networking code). Thanks again for your advice.
I agree completely with your comments on Sender/Receiver and Transfer(er). In fact, Transferer had become almost trivial and so I removed it entirely. I suppose this it was left over from my earlier plans plans when I thought there would be more functionality shared between Sender and Receiver, but even then as you say it should have been encapsulated rather than inherited.
As for Node Comm and Root Comm, they do rely on polymorphism. They are mostly used in exactly the same way by the applications containing them, however they differ in terms of establishing connections and broadcasting, amongst other things.
Sender and Receiver do indeed need to access Comm Reference List, or individual Comm References at the very least. This was omitted because I need to relate neighbouring areas of the world to the Comm Reference that allows communication with them, and at the time I wasn’t entirely decided on how this would be managed. Sender and Receiver now have access to the Comm Reference List, and segments of the world are related to Comm Reference IDs in a separate lib for managing the world.
And finally, that’s correct. My world is divided into numerous cells, and each worker node is responsible for processing a series of these. I’m trying various methods to divide these cells over the available nodes (and hopefully the minimum required nodes if I can calculate that reliably), both statically and dynamically. I would imagine the more successful solutions will be when the cells being processed by a given worker node are contiguous, but this will not necessarily be that case all of the time with every method.
Again, thank you very much.