How to change hosts entries on network changes


I am changing some special hosts file entries according to different networks, I am connecting to.
One is with Direct Access (DA) into my companies’ network, that works with IPv4 address resolution. The other one is directly connecting to the office’s network, using IPv6.
So I have to change my entries by hand, to reflect address resolution, every time, when I am changing between these two networks… and that is really annoying.

After a couple of years (right…! doing this day by day with the goal, finding a way out next day (every day), I passed over years ) and many, difficult to track, issues, that could easy by solved by not forgetting to change theses entries in hosts file, I tried to find a solution….

…and here it is!

It is that simple, that I shouldn’t post it here, to save my face 🙂. But I think, I am not alone with that.

Windows Tasks Scheduler is the key. So, let me explain:

Think of a simple hosts file entry:


(Currently I am connected by DA over IPv4, therefore I uncomment the second line and commented out the first one.)

For automatically changing these settings to the invert, I can (and of course, there are other possible solution) create a Tasks, that runs on detected NetworkProfile change. With a little powershell script the right settings in the hosts file will be modified. So have an eye on the following instuction:

  1. Open Windows Tasks-Scheduler
  2. Create new Task by right clicking somewhere in Task Schedulers tree
  3. In next dialog enter a Name for the task
    1. (it’s up to you, to decide, whether to choose running with logged on user or not)
    2. Making changes to hosts file is only with administrative privileges possible, so click “Run with highest privileges
    3. Also set the configuration in respect to the running machine
  4. Switch to tab “Triggers
    1. Select at “Begin the task:On an event
    2. Search for Microsoft-Windows-NetworkProfile/Operational at “Log:
    3. On “Source:” select NetworkProfile
    4. As “Event-ID:” enter 1000 (means “Network changed”)
  5. OK… coming slowly to an End…
    1. Switch one tab further to “Actions
    2. Leave “Start a program” in “Action:
    3. Now we want a Powershell script to be triggered on the networkchanged-event
    4. So… add as “Program/Script” name PowerShell.exe
    5. As “Add arguments (optional):” add script’s path
  6. If you are not willing to spend the time into selecting the right event, but want to achieve the same result here is a simpler solution
    1. Switch to tab “Conditions
    2. Select last checkbox and choose the network that triggers
  7. Save everything an go to next step….

The triggered powershell script

Now, everything is ready to run something an the networkchange event. So here come the script (I do not have to mention, that there are more elegant ways):

(again my example hosts file)

In the first line the script retrieves the network profile name (the name, that is also listed in that combobox in picture 6.b.). In relation to the name of the current netw.profile, all lines in the hosts file, that contain the string “wlan” will be uncommented and others with “home” commented.

The result after network switch is :

Making ActiveMQs Topics virtual for use with Queues

The problem

Before I start explaining the core part, I will tell you the reason, why I am posting this.

or directly to the solution

Everything started with RabbitMQ 😉 in a major enterprise IoT-project for a well-known german refridgerator producer, that has been mentioned by Satya Nadella at the Hannover-Messe in Germany in 2016.
The goal was, to bring smart devices online with a common messaging protocol. But because of some issues with the broker (handling some sort of certificates), the decision has been made, to replace RabbitMQ by ActiveMQ.
The problem (technically) with that decision was, that all sinks of messages send to the broker with MQTT, will be handled by ActiveMQ as Topics. This leads the whole communication architecture to be not scalable.

Please let me explain some details regarding Scalability and Topics vs. Queues…

If you like to have an IoT-Architecture, that is scalable, than you should enable your environment to handle as much messages as possible in parallel. To achieve this, you have to decouple logics/functions into Worker-Units. With this, you can higher the number of parallel worker, that can then consume messages parallel. As you can see… this is scaling! But, what is very important, to point to, is that these workers can only consume messages parallel, if the source of the messages (where worker consume messages from) delivers messages with FIFO pattern (or one in one out). This also known as queuing concept.

are constructs, that allows consumer, to handle only one message at a time. With that you have a concurrency enabled environment, where all consumers are “battling” for messages. So with this pattern, you can keep queues “empty”. And, if there is more load at the system, then you can scale by awaking some more instances of the same worker.


The other, let’s call it “message handling strategy”, is Topics. The idea behind this is, to have multiple different worker consume on topic-related messages. Think of the following scenario, you have a smart device, sending notification, alarms and other emergent messages; But also it sends some logging/monitoring messages. Further you like to have some backend modules, that handle these different types of messages in a different manner, then you need Topics. A message would then be routed to either a topic called “Alerts” or “loggings” or whatever…. With that strategy you deliver one message to all the consuming workers listening on the same topic.

The problem with change of broker

Maybe, you can see the main problem with the broker-change… after changing from RabbitMQ, that handled all the messages send by MQTT protocol in queues, the concept changed to topics, because ActiveMQ handles MQTT messages with topics-Strategy.

[Quote: “ActiveMQ is a JMS broker in its core, so there needs to be some mapping between MQTT subscriptions and JMS semantics. Subscriptions with QoS=0 (At Most Once) are directly mapped to plain JMS non-persistent topics. For reliable messaging, QoS=1 and QoS=2, by default subscriptions are transformed to JMS durable topic subscribers. This behaviour is desired in most scenarios. For some use cases, it is useful to map these subscriptions to virtual topics. Virtual topics provide a better scalability and are generally better solution if you want to use you MQTT subscribers over network of brokers.“, ]

And that makes our architecture become inefficient/ not scalable. One possibility to get out of this situation, is to change that smart device to send by AMQP (for example), but this would mean, to change the whole project plan and with that time to market. Or you make some “magic” configuration stuff at brokers side J… as a second solution.

The solution

How to change Topics to virtual topics

As a developer in the eco-system of Microsoft (Visual Studio, C#, .Net,….) it is not so trivial, to get into this Broker and understand the different concepts, “languages” and further “strange things” that are used with ActiveMQ. Also the documentation of that broker is not that detailed and easy to understand, if you only want to use this product. (but that is understandable, because no one should use it as an OOB-Tool). But I think this solution here could be found useful for other devs, like me, that are only looking for a solution to get around the problem, I explained before.

First: Config

Somewhere in the install folder of ActiveMQ…

There is a “conf” folder, containing the activemq.xml. There you can find your allowed and configured connections in the section transportConnectors.

In the excerpt below, you can see the line, where mqtt protocol is enabled. This line gets extended by ActiveMQ parameter for subscription strategy (see below).

If you haven’t already, than you should fix you code as well, to read from queues:

  • Create consumer for Queues instead for topics and pass the new path-pattern…
  • With virtual Topics the name of the queue is changed to a pattern as follows. Consumer.Application.VirtualTopic.QueueName.
    A example… If you send a message to topic Alert by the pattern smartDevice.number.Alert this will change to (from Broker or consumer perspective) VirtualTopic.smartDevice.number.Alert
    That is then consumable by that path(e.g.): Consumer.AlertWorker.VirtualTopic.smartDevice.number.Alert (means, I have a worker (or multiple instances) handling alert messages from the queue “Alert” of a specific device).
    You can also use wildcard characters like * e.g. Consumer.AlertWorker.VirtualTopic.smartDevice.*.Alert (means, I have a worker (or multiple instances) handling alert messages from the queue “Alert” of all devices).
    .. and so on.

I hope someone can make use of this solution, otherwise it may lead to another. Please share your thoughts!

Making event handling scalable

Today I am working on an IoT enterprise project. And as all of us know, there are thousands/ millions of messages arriving at the message broker and sitting there for being consumed by decoupled worker, computing and managing all the different types of messages.

The special thing, I am currently working on, is a kind of configuration worker, that is generated automatically by a “main worker”, that pre filters massages and so on – I will not discuss the architecture in that article (maybe in a later post). This post is not about IoT infrastructure,where goal is to make parallelism and scalability possible for device-to-cloud-communication. It is about the same achievement, but for events in a software component itself.

The Pipeline-Pattern is the key

Consider following common scenario: you’ re trying to handle multiple messages in a software unit arriving as events on a handler. The unit reacts with some heavy computational algorithms or long running ops on services, files,… . A traditional way would be, to hook up a handler, that calls some methods handling the content of the arriving message. Because of the nature of event handler, there are multiple handlings on multiple messages possible. So why changing the pattern?

I think common IoT scenarios are showing, why. They are not that different to events and handlers on your application. The problem is ‘blocked ressources’! If there are handler, that are running long, then it is not guaranteed to process other handlers in parallel. Another thing is also scalability of processing. But how can Piplines help out?

Consider now following solution: an event/message arrives and will be stored into a queue. At the other end of that queue, a receiver can consume the message, when there is time left for working on messages. A queue is by nature a system, that decouples. Also a sender can put into a queue as along that queue has enough space left. So, with that concept, an event handler is able to receive events and also has not to care about anything else, but its main objective – handling events.

Give me code!

Here is an example, of what I mean (it’s written in C# ).

Old way:

Way with Pipeline-Pattern: