<p>This is a general question but for arguments sake you may and assume we have a collection of processes communicating via a combination of AMQP and HTTP. There are two specific cases to consider.</p>

<p>The easy one:</p>

<ul>
<li>Q) If A sends a message to B how does B identify the location of A to send a reply.</li>
<li>A) A must tell B where to send it somehow (exchange for AMQP, URL for http)</li>
</ul>

<p>The harder ones:</p>

<ul>
<li>Q) How does a monitoring process send a message to A (where something else has prompted this desire - e.g. B says A sent me a bad request)</li>
<li><p>Q) How does a monitoring process kill or restart A.</p>

<p>This could be something like kill a host+pid or a pod or a pod+container </p>

<p>(see for example <a href="https://stackoverflow.com/questions/46123457/kubernetes-restart-container-within-pod">kubernetes restart container within pod</a>)  </p>

<p>You might wish to restart an entire service or some subset of the processes that are providing that service.</p></li>
</ul>

<p>Now you can assign a UUID yourself but you need a table to map it.
This may have multiple columns but sometimes a single URI (or URI like thing) is useful for example as a "originated from/reply to" address.</p>

<hr>

<p>Another way to view this question.
In the old days it was easy to identify a process.</p>

<p>A hostname (or IP address) + a PID was sufficient</p>

<p>Then came virtualisation the IP address identifies the virtual network port assigned to the VM and the PID identifies the process within it.
A hostname and IP address are still sufficient.
Sometimes you need the vhost as well (though I was never clear why)</p>

<p>Now adding containers to the mix a container doesn't necessarily have a IP address of its own. A <a href="https://stackoverflow.com/questions/39931316/what-is-the-pid-in-the-host-of-a-process-running-inside-a-docker-container?rq=1">host+pid can identify the container</a>
But you might not know the host if you are running kubernetes or docker swarm.</p>

<p>Now we don't talk about processes so much anymore as about services.
It used to be enough to identify a service using a hostname (or IP address) and a port (YMMV - <a href="https://stackoverflow.com/questions/8731714/can-an-ip-address-and-a-port-number-together-uniquely-identify-a-process-id">Can an IP address and a port number together uniquely identify a process ID?</a>).</p>

<p>Now we have load balancers and other tricks (e.g. caching proxies) to redirect messages to something else that actually provides a service.</p>

<p>A service might be provided by a container or a pod containing several containers in which case you may want to address the pod or the container.
See for example <a href="https://stackoverflow.com/questions/46123457/kubernetes-restart-container-within-pod">kubernetes restart container within pod</a>
It looks like container names are unique per docker instance but not beyond that.</p>

<p>So there a few different ways you might want to address a message.
Is there a good standard way of doing this?</p>

<p>To my mind the obvious thing to use is a URI (but I could be wrong). 
Are there recommended URI forms to handle <strong>all</strong> possible cases?
(obviously we have <em>procotocl</em>://<em>host</em>:<em>port</em>/ for the easy cases)</p>

Bruce Adams
<p>After some consideration I believe host+pid is still sufficient (but not necessarily the best way) to identify a process providing you are mindful of the following:</p>

<ul>
<li><p>whose PID you mean could be ambiguous.
It could be the PID of the container's namespace or the host.</p></li>
<li><p>If you are referring to the process from outside the container you need to use the PID of the host not the PID as it appears inside the container as this is in a separate process namespace. 
See for example <a href="https://hackernoon.com/the-curious-case-of-pid-namespaces-1ce86b6bc900" rel="nofollow noreferrer">the-curious-case-of-pid-namespaces</a></p></li>
<li><p>The container may evem be able to identify the host and PID itself (after all it is supposed to be a sandbox)</p></li>
<li><p>IP addresses will be relative to the internal network (as normal)</p></li>
<li><p>hostnames will go via DNS lookup (as normal)</p></li>
</ul>

<p>Now a URI refers to a port not a PID so a URI is not appropriate here. PID@HOST is probably a sensible notation but beware confusion with user@host.</p>

<p>In addition to container and pod Ids there are other more convenient ways to identify a processing resource such as <a href="https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/" rel="nofollow noreferrer">stateful sets</a> </p>
