I’ve been spending time testing and tightening things up.
Console Host: The console app is what I have been using, since day one, to develop and test with. It has 2 hard coded nodes and a hard coded hub. I use comments to control what I need or don’t need for whatever I’m doing.
I wrote a new console host app that’s much nicer. It also servers as an admin client.
You can create and manage as many nodes as you want through the command line interface. All of these nodes are hosted in the same process, which is useful for development and testing.
It can also be used to make http api calls to the hub (which is probably in the same process.)
As far as the program is concerned, everything you type is just a command. But, there are three types of commands:
* bus messages – the message will be sent on the bus
* local command – this is something that is coded for in the console app. it does things like clear the screen, start/stop nodes, start/stop hub, switch to a node of your choice. (IE: if you have 3 nodes in process, and you want to send a message, from which node do you want to do it? the SETNODE local command will give you a reference to the bus of the specified node
* http command – makes an http api request
Even though they are all commands, I don’t want them all jumbled together. I want it clear which commands do what sorts of things. So, when you type a command, you prefix it.
. – it is a local command
/ – it is an http command
nothing – it is a bus message
Here are some sample commands. This is the code I use to initialize my test server.
.starthub – creates and starts the hub in process
.createnode node1 – creates a node in process
/setmodel node1 Application_Server – make an http call that sets the node type.
.startnode node1 – starts the node – in process
/setmodel node1 Reporint_Server – make an http call that changes the node type. (This results in a a sync message being sent. node1 will stop, sync, start it’s applications.
I also have command to start/stop signalr, which is useful to make sure the clients handle disconnects and reconnects properly.
App Host Feature and Synchronization
I did a lot of work on synchronization a few months ago. I thought it was done. But, more work was needed. I reviewed it top to bottom, and made some changes.
The AppHostFeature was recently overhauled to make parts of it swappable. I never really finished that until now. Everything is starting/stopping gracefully.
It seems to be a popular opinion that, when doing rest, you don’t really need a client. Yes, I still see a lot of them. I created one for the app server. So far, it only does a couple things as needed by the console app. But, it will grow.
To keep the references minimal on this DLL, I’m not including the contracts. It builds up the JSON manually (via json.net) rather than through serialization.
I was surprised to see that HttpClient doesn’t support patch. You have to build it up manually. I’m using patch in one place: to change the model type or the group of a node.
In that case, Patch is appropriate, but it’s not always called correctly. If you PATCH a node that doesn’t exist, it defines the node. I’m pretty sure that’s bad REST, and I have a todo to address it.
The SignalR server is working well, but I’m having a bit of an issue with the client. I can’t get it to reconnect reliably. I’ll work on that.