tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: proposal: inetd improvements.



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.

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.

Dennis Ferguson


Home | Main Index | Thread Index | Old Index