Migration to Broadcast only

angelb at bugarin.us angelb at bugarin.us
Mon Feb 20 10:13:56 PST 2006


> > b. The servers Broadcast function follow the same rule as the
> > client's polling function. That is, it uses Broadcast interval to
> > send out updates to the network. Setting the interval to a low
> > setting, say very five minutes, will have an effect on CPU use on the
> > client. Setting it to a higher setting, say every 60 minutes, will
> > mean that changes will not be available to the clients until the
> > update starts again.

> Correct, however in CUPS 1.2 we actually save the remote printers
> between runs.  A user that reboots their system will immediately have
> the full list of printers available (no waiting after the initial
> discovery)
>

That's good to know. But here's a suggestion, if it even makes sense.

Why not just eliminate the printers list from the clients entirely? If you do this, it doesn't matter whether you're polling or broadcasting,
the clients will still be able to print. This will eliminate the high
CPU use on each client and packet flooding on the network among other
things.

Let me start with this: Does the client need to know what printers are
available, changes made, printer status, offline, online, etc? No, the
clients doesnt have to know these details because the servers already
know that.

So then, if the clients doesn't know anything about the printers in the
servers, how can it request a print service? Simple, the cupsd.

Here's where I'm getting at: If I wanted to print a document to a
printer, I should just be able to pick a printer name off the air and
let the cupsd take that name and along with my document and forward it
to the servers. It's up to the servers to resolve that printer name
whether it exist or not, offline or online, etc, and then sends back
a reply or status to the client accordingly.

It's like DNS, not that I'm an expert in DNS or anything, when a user
enters a www name on its browser, the user does not need to know
whether that name resolves or even response? No, it relies entirely on
the browser to do all the work for him and the browser will return the
appropriate site or error message accordingly. If the cuspd on the
client system can function that way, I'd say it's far better and more
efficient than sticking with the printers list.

The ONLY information that the clients should get back from the servers
after sending a job are the status of "Print job completed" or "Print
job failed" and should not be bothered by anything else.

If CUPS can be configured this way, I'm almost certain there will be
much rejoicing and dancing :) in the CUPS users community.

I appreciate your replies. I'm looking forward into testing 1.2.

Angel




More information about the cups mailing list