Messages received by CASUs only provide the "physical" name of the sender, not the logical label

[rmm-fcul]

It should be feasible to define CASU responses to messages from different neighbours, and to do so logically. At present, incoming messages are stamped with the name of the CASU that sent the message, and not the logical label of that neighbour. (I've called it "physical" above, but it isn't quite the right word).

For example, with three CASUs: A,B,C, and links B->A, C->A, we might have the following configuration:

name: A
msg_addr: tcp://*:50300
neighbors:
    excit:
        name: C
        address: tcp://localhost:50200
    inhib:
        name: B
        address: tcp://localhost:50301

In this example, C is the "physical" name for one neighbour (tcp://localhost:50200 is the physical address), and excit is the logical label for the neighbour.

The issue is that the incoming messages should provide the message sender in terms of the logical label, and not the physical name. (Or possibly provide both, thus maintaining backward capability).

[rmm-fcul]

The RTC files contain sufficient information to resolve, and since the file is parsed on initialisation of the CASU handler object, we can read in the mapping at the same time. This mapping should be {'name' : 'logical_label', ...}

Two possible uses of information:

1. the Casu.read_message() method does a lookup, and adds the logical name to the msg dictionary before returning (also handling the case of an unknown sender).
2. a new Casu.identify_sender(msg) method provides the same functionality, but is only invoked by the user if needed.

My preference is for (1) since msgs are dictionaries anyway, and the extra data is only one dictionary lookup and the user shouldn't have to work for it every time.

[dmiklic]

I agree, (1) seems like the right solution. We should just figure out a meaningful key under which to store the "logical_label". Simply "label" sounds good to me.