[nanomsg] Re: Directory service for nanomsg ??
- From: "Jason E. Aten" <j.e.aten@xxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Mon, 4 Aug 2014 15:38:11 -0700
A server can't know who is making the request. Hence any server will have to
return all three answers and let the client pick the right one.
> On Aug 4, 2014, at 1:59 PM, Soren Riise <sorenriise@xxxxxxxxxxx> wrote:
>
> 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:
