-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Rogers schrieb: | David Sowder wrote: |> Cloud 1 and Cloud 2 need to be using the same N2NM type ID number for a |> particular service if any of [A, B, C] connects with [D, E, F] if such a |> connection is to then allow all of [A, B, C, D, E, F] to potentially |> talk to each other because otherwise would involve some sort of |> "difference resolution protocol" to force either [A, B, C] or [D, E, F] |> to change their service name to N2NM type mapping to either the same |> N2NM type ID number of the other or a third N2NM type ID number used by |> [A, B, C, D, E, F]. | | If you view the ID as a port number rather than a message type then | there's no problem. Node A runs the service on port 123, node B runs it | on port 456, etc. When you want to connect to the Foo service on a | particular node, contact its lookup service and get the port number for | the string "Foo". The string, rather than the port number, identifies | the service. Different instances can have different names (eg Foo/Alice | and Foo/Bob). |
If we use names we also have to ensure, that there are no duplicates (e.g. two apps named foo). It would be no problem to give names on a first come first serve basis (first app gets foo and the second foo2) but if the fcfs is applied different on the node we want to exchange messages with (e.g. because we only started the second app or both in another order) foo requests foo on the other node but gets foo2. This can be solved by providing something like ICANN. So as we need some fixed Table in any case I would prefer David's method to keep it simple. Neo at NHNG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHjUxbPUBAMhFf+J4RAsN9AJ4qdTpsdrTEn8na9KnJNHDbYOwtTgCcCEox 6E3/XIMWk0v57toiLjyPVM8= =etqC -----END PGP SIGNATURE-----
