Reconsider using bin-name+network-address as the Unique ID

[aletheiawarellc]

Reconsider using bin-name+network-address as the Unique ID

[stuartmscott]

It is probably best to split this ticket up. Let's keep this one focused on identity, use #39 for optimizing local message passing.

[stuartmscott]

Yup, each machine has a unique identifier composed of the binary name (eg switch/Switch) and network address (eg 12.34.56.78:64646).

The network address is unique as a port can only be bound to one machine, and machines can't change addresses or binaries - instead stop the machine and spawn the desired binary on the desired address.

"networks will likely not be used" I disagree - a single machine can fail, multiple machines are a requirement for fault tolerant systems.

include, source

[winksaville]

I have a feeling for safety critical applications where the replication is across devices connected by a network. Each of those devices will contain multiple SMs connected locally. Thus my contention that "most" of the connections between individual SMs would **not ** be via a network. But, obviously, it depends on the task.

[winksaville]

In general I like the #38 solution, but I'd like to reiterate that assuming a "network" protocol as the only way for actors to communicate is too limiting in the long term.

In Rust and Go "channels" are used for communication between entities within a "system" (i.e. communicating between threads or async/coroutines). Also, in embedded systems I can envision an interrupt service routine to be able send a message to an "interrupt handler". In both of these examples it's unlikely that a "network" connection would be used as "serialization" is required and that is much slower than sending pointers between nodes. That isn't to say you shouldn't merge #38, but I don't think it should close this issue.