CUPS 1.6 shaking up Linux printing

Posted Mar 10, 2012 19:13 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
In reply to: CUPS 1.6 shaking up Linux printing by dlang
Parent article: CUPS 1.6 shaking up Linux printing

>auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

How? Autodiscovery mechanism generally work by flooding the network with broadcast/multicast updates. A misconfigured node should just be silently ignored.

I assume you're not talking about DHCP/RA.

to post comments

CUPS 1.6 shaking up Linux printing

Posted Mar 11, 2012 5:01 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

>auto-discovery has the problem that if any node is mis-configured (either accidentally or deliberately), it can break the entire network.

How? Autodiscovery mechanism generally work by flooding the network with broadcast/multicast updates.

Exactly.

A misconfigured node should just be silently ignored.

Only if you disable autodiscovery (how else can you prevent flood organized by misconfigured node from affection configuration of the rest of the network) - but then what's the point of the whole exercise?

I assume you're not talking about DHCP/RA.

Actually DHCP is not any different: if a single node hogs all available IPs from a DHCP pool then other nodes will be unusable.

All autodiscovery mechanisms have this problems - and DHCP is not an exception. It also shows that on practice problems are rare: sure, DHCP autodiscovery may fail too and it even happens from time to time but if you'll consider how ubiquitous it is and how rare are such failures… I think we should not fear autodiscovery mechanisms all that much. 99% of users use [limited] version of autodiscovery with TCP/IP and sky have not fallen so why can't we use somewhat more advanced version and get the convenience offered by proprietary networks 20 years ago?

CUPS 1.6 shaking up Linux printing

Posted Mar 11, 2012 6:24 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

I don't consider DHCP an autodiscovery mechanism.

That's a server that responds to queries (although very bad things can happen if you end up with unexpected DHCP servers on a network)

Autodiscovery in this context is when everything tries to advertise what services it offers to everything else on the network. In a small network this can work, but in a large network you end up with chaos due to too many things advertising services that you don't care about, and either meaningless auto-generated names, or conflicts between human generated names

CUPS 1.6 shaking up Linux printing

Posted Mar 11, 2012 7:31 UTC (Sun) by khim (subscriber, #9252) [Link]

I don't consider DHCP an autodiscovery mechanism.

Just like I don't consider reference-counting schemes “real GC”, heh. Well, true it's “autodiscovery lite” mechanism: it's more limited and thus more tolerant to problems with clients… but it introduced “single point of failure” so it's also not ideal.

Autodiscovery in this context is when everything tries to advertise what services it offers to everything else on the network.

This is not a requirement. Devices on network can play different games. For example they can choose single master which then arbitrates everything. Of course this implies some level of trust which may or may not be appropriate for real world.

In a small network this can work, but in a large network you end up with chaos due to too many things advertising services that you don't care about, and either meaningless auto-generated names, or conflicts between human generated names

Right, but in large network you probably have a dedicated sysadmin which can setup everything as is needed. But for something like home network autodiscovery may be invaluable.

P.S. Interesting twist in the GC debate: iOS5 added ARC and a lot of guys viewed it as an “incremental step on the road to real GC”, but looks like Apple shares my POV: beginning in OS X v10.8, garbage collection is deprecated (if favor of ARC if I understand correctly).