Re: proposal: inetd improvements.

[elric%imrryr.org@localhost]

On 1275694244 seconds since the Beginning of the UNIX epoch
Dennis Ferguson wrote:
>

>On 2 Jun 2010, at 12:57 , elric%imrryr.org@localhost wrote:
>On 1275508087 seconds since the Beginning of the UNIX epoch
>> Dennis Ferguson wrote:
>>>
>>
>>> On 2 Jun 2010, at 03:16 , elric%imrryr.org@localhost wrote:
>>>>    4.  % should be defined as an address type and it should expand
>>>>        into a list of IP addresses which is periodically =
>regenerated
>>>>        by iterating over the interfaces,
>>>
>>> I'm curious what the purpose of this is?  The reason I'm asking is that
>>> doing this can just really, really suck on routers which have large
>>> interface configurations (I've seen them with a number of interfaces
>>> configured which overflowed a 16 bit interface index).
>>>
>>> Since this may introduce a scaling issue in some (admittedly far corner
>>> case) applications it might be better to avoid it by instead fixing the
>>> thing that makes you want to do that, even if you don't care about
>>> the corner case.
>>
>> It's specifically for UDP wait services where the client expects
>> the server to answer from the same IP address to which it sent the
>> request.  E.g. named or krb5kdc.
>
>Got it.  When you implement this it would be good if you avoided scanning
>the interfaces altogether unless someone actually configures the thing which
>requires you to do this.

Yes, that's planned.

>The systems I've seen which run with big interface configurations
>have provided recvmsg() the option of telling you the destination
>address of each incoming packet and have made sendmsg() accept the
>source address to use for each outgoing packet it sends so that
>UDP daemons could be made to do the right thing with only one socket
>open.  As long as you don't assume that UDP services must run with
>multiple sockets then this will be maximally portable.

This involves some level of extension to the standards and hence
isn't incredibly portable and many things like BIND and MIT's KDC
just do the multiple interface approach.  Of course, one wouldn't
want to force people into this sort of thing but I think that it's
a useful feature to have given that there are a number of daemons
that expect to work this way.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/