[nanomsg] Re: The name service for nanomsg
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Sat, 7 Sep 2013 12:33:49 +0300
Hi Martin,
On Sat, Sep 7, 2013 at 8:47 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> On 06/09/13 11:21, Paul Colomiets wrote:
>
>>>> Right. Also, socket options could be provided by the name service
>>>> (priorities, or whatever).
>>>
>>>
>>> I don't follow that last point. Should name resolution really solve that
>>> problem? Or should it just solve the problem of turning NAME into a
>>> string
>>> like "tcp://127.0.0.1:1234"? I would be in favour of the latter.
>>>
>>
>> Yes. Look at how DNS SRV works. It gives a list of addresses with
>> priorities and weights.
>
>
> I would go further than that. Have a look at options in nanomsg and you'll
> see that almost all of them should be set by admin rather than programmer.
> Take, for example, reconnect intervals: Programmer has no idea what
> intervals are appropriate in the destination environment. Only the admin has
> enough knowledge about the deployment environment to be able to decide on
> correct values.
>
> I would say that even an option like TCP_NODELAY should be set by admin
> rather than by programmer. What it does, in fact, is trading some bandwidth
> for better latency. And once again, it admin who knows about bandwidth and
> latency specifics in the deployment environment so it should be his
> responsibility to set the option.
>
It's temping. Still we should think very well before putting so much
configuration info into name service. While it's possible to send some
socket options though name service, I don't think application can live
without configuration at all.
We may invent "configuration service" rather than name service. But
that would mean we need a way to discover other, application-specific
parts of configuration.
Thoughts?
--
Paul
Other related posts:
