Addressable Terminators

Goals

We already allow multiple applications to provide a single service. We want to now also provide a way to address a specific application provider.

Use Case Overview

If we have many instances of an application running, and each of them want to talk to each other the only way we currently have to do that is by creating a different service for each instance. It would be easier if we could specify a specific application hosting a service to communicate with.

Example

If we have a VoIP service, every application is both hosting and consuming the service. If the service is called voip, we could reference specific clients by phone number or name.

In order for this to work, we need two things:

1. A way for applications hosting a service to provide their identifier while binding
2. A way for applications consuming a service to provide a specific identifier while dialing

Both of these could be supported by allowing the identifier to be passed in as part of the service name using a special character (like @) as a separator.

• Bind 555.555.1234@voip
• Dial 555.555.1234@voip
• Bind dev.smith@voip
• Dial dev.smith@voip

Addressable Terminators

Every application hosting a service is already represented in the model by one or more terminators. What we don't have is a way to figure out which terminators are associated with a particular application instance. If we allow the hosting application to provide a unique identifier, each terminator created by that instance can be tagged with that identifier. Then dialing applications can use the same identifier to select that instance to communicate with.

For now, let's call the new field Identity.

Additional Benefits

We could also use the knowledge of which terminators belong to a specific instance to route to allow multiplexing connections. This would allow us to create multiple paths (including multiple exit routers) and treat it is a single path. This could allow for improved performance as well as provide redundancy within a single session.

Guardrails

Service Type

We would probably need to add a flag to service to indicate if providing a Identity while dialing is forbidden, optional or required. For some services it wouldn't make any sense to provide a host id, or might break things. For example, it might allow a user to specify the secondary server in an HA setup, when the primary hasn't failed. For others, it wouldn't make any sense without a Identity, for example in the voip scenario. You wouldn't want someone to be able to dial a random number.

Identity conflicts

We might also want to provide a way to guarantee that different instances of an application can't claim the the same Identity. For example, if two instances of a VoIP application both claim the same phone number, call to that number would end up going to both instances at random. One way to do this would be to allow clients to also submit a secret with the first terminator created. Subsequent terminators with the same Identity would have to submit the same secret.

Potential Issue: If the application use a secret generated at startup, crashed and then tried to reconnect, they wouldn't be able to reconnect until the terminator was removed, which might take a short time. It might be safer to remove any terminators which don't match if a new secret is submitted. The Edge could use a stable secret, something like the hash of its cert.

Identity Validation

We might to ensure that only authorized application instances use a specific Identity. One way to do this would be to allow the Identity to be provided by a plugin. For example, if the edge is available it could have the Identity stored in an identity tag. Then the client couldn't override the Identity.

New APIs

This wouldn't change the SDK application APIs. It would just add new meaning to services specified with a <identifier>@<serviceName> format. We would probably add a new optional field to bind for specifying a secret.

It would be nice to also provide an API which would let you query all active Identities for a service.

NOTE: If there are multiple terminators with the same identity we shouldn't return the same identity more than once.

Would we want to allow providing additional metadata on Bind along with the host id? This would let you bind with something like:

Bind("dev.smith@voip", "{ \"firstName\" : \"Dev\", \"lastName\", \"Smith\"}")

This might represent scope creep, though, and could be better done with an external system.

Dial Source

We currently don't provide the information about who is dialing. We should see if we can pass that through so that the hosting application can get the identity of the dialing application