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

[winksaville]

Identifiers are very important and I think there will be a need to link ID's into a hierarchy for versioning, "VersionedId". Also, as I see it, an SM instance will "advertise" a set of Protocols it supports. Where a Protocol is a set of Messages. So each SM, Protocol and Message should have a VersionedId.

As for SMs, I don't see them having a static location nor will a single binary have a single instance so I don't think bin-name+network-address is an adequate ID. Also, networks will likely not be used for SMs communicating within a process which, IMHO, will be the most common case for how SMs communicate.

I'd like to suggest considering something like a UUID or Web3 ID as the basis for identification. I have no firm idea how to create a VersionedId, but I'm sure it's possible, maybe using Web3.

[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.

[stuartmscott]

It is probably best to split this ticket up. Let's keep this one focused on identity, use https://github.com/AletheiaWareLLC/Wink/issues/39 for optimizing local message passing.