[nanomsg] Re: Directory service for nanomsg ??

  • From: Soren Riise <sorenriise@xxxxxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Mon, 4 Aug 2014 21:59:06 +0100

Thanks Jason,

My understanding of LDAP is that it will return canonical information -- where 
the needs for the use im suggesting is that it returns different information 
depending on who is asking.

I.e. who is asking is as important as what is being asked, so that the best 
connection address (inproc, ipc, or tcp) can be returned to the requester, 
without additional logic at the requester's end.

Is there some aspect of LDAP which I have missed which would allow this logic 
to be in the LDAP server?


Soren





________________________________
 From: Jason E. Aten <j.e.aten@xxxxxxxxx>
To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx> 
Sent: Saturday, August 2, 2014 8:35 AM
Subject: [nanomsg] Re: Directory service for nanomsg ??
 


OpenLDAP
http://www.openldap.org/doc/admin24/intro.html#What%20is%20a%20directory%20service
The LMDB based implementation is very mature and highly performant.

Best,
Jason



On Aug 1, 2014, at 4:58 PM, Soren Riise <sorenriise@xxxxxxxxxxx> wrote:


Hi
>
>
>Im building an grid application where peers in the grid may be in the same 
>(mt) process, same machine or on a remote machine.   I really want to abstract 
>out the need for knowing in advanced if a connection needs to use 
>tcp://somehost ipc://somename or inproc://somename -- so my thinking is that I 
>can create an abstract address for each connection and then implement a 
>resolution service where;
>
>
>-- new resources when created -- binds to both inproc, ipc and tcp and then 
>provides that details to the resolver
>-- new clients then ask the resolver for how to connect to 'xyz' and if 
>                    -- in same process, return the inproc
>                    -- same machine, returns the ipc
>                    -- otherwise returns the tcp end point
>
>
>However it occurs to me that this could be a quite comment requirement, and 
>that it may already exist -- so better ask here before starting such 
>project....
>
>
>Any pointers or suggestions?
>
>
>
>
>Soren

Other related posts: