-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reconsider using bin-name+network-address as the Unique ID #11
Comments
Yup, each machine has a unique identifier composed of the binary name (eg 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. |
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. |
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. |
It is probably best to split this ticket up. Let's keep this one focused on identity, use #39 for optimizing local message passing. |
* Support optional version and tag Fixes: #11 * Update README * Fix family sample * Polish * Switch to seekg * Drop _v separator * Complete SemVer comparison
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.
The text was updated successfully, but these errors were encountered: