synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <>
Subject Re: inter-synapse links
Date Thu, 13 Dec 2007 17:08:41 GMT

> 2. We have a central registry and each Synapse node publishes to that
> This will work when the whole configuration is stored in the registry.

Well it doesn't need to be the whole configuration. It simply needs to be
just the endpoints.

3. We have URL on each node which the other nodes can use to query and post
> > their own endpoint definitions. This could even be federated (in other
> > words, I don't need to specify the URLs of ALL the other Synapse nodes, just
> > one. As long as each Synapse node is connected the mesh, then it can get
> > info on all the others via the mesh, then all the addresses propogate. This
> > could be really cool... sort of a distributed mesh registry of Synapse info.
> > No central server required and no single point of failure.
> Paul, I am sorry, but I don't really get this idea.

Ok let me try and explain again.

Imagine there is a web service by which a synapse node can:
1) publish a map of proxy services to endpoint URLs that are supported on
this node
   e.g. {thisnode->{{proxy1: url1,url2,url2}, {proxy2: url4}}}
2) read a map of proxy services to endpoint URLs that are available on all

I guess to do this properly you might need a global revision number like SVN
so you stay completely consistent and you know which updates are fresh.
(There might be some complexity if two systems think they have the latest
info and have never communicated before, but I bet there is a nice algorithm
for this)
Given this interface every node can find every endpoint for every deployed
proxy, as long as each node can contact at least one other node (i.e. there
is a *mesh*).

Now actually this need not just be for Synapse endpoints. If you had the
same config for all endpoints, you could also use this to distribute the
config. So a server could be started with only two pieces of information -
which role(s) its playing, and the URL(s) of one (or more) other server(s)
in the mesh.

[We could also have this for Axis2 so that Axis2 endpoints can also become
part of the list, but that is another conversation I think needs to wait]

Does that make more sense?


View raw message