Hello
Rafael Roquetto
I work for a company which works on a heavily modified version of NX
code, with support for printing, audio, file transfer between remote
and local parts, and so on.
How do you plan to implement printing tunneling?
Should you wish, I would be please to help you. I believe we have
undergone many problems you might run into. Hence, feel free to take
on me.
Stephen Shirley
> I work for a company which works on a heavily modified version of NX
> code, with support for printing, audio, file transfer between remote
> and local parts, and so on.
Wow, cool.
> How do you plan to implement printing tunneling?
Honestly, we haven't thought that far ahead just yet -)
> Should you wish, I would be please to help you. I believe we have
> undergone many problems you might run into. Hence, feel free to take
> on me.
Great to have you around!
Steve
--
"You are technically correct, the best kind of correct."
- Bureaucrat 1.0, Futurama
Rafael Roquetto
>
> On Tue, Jul 14, 2009 at 20:45, Rafael Roquetto<rafaelr...@gmail.com> wrote:
>> I work for a company which works on a heavily modified version of NX
>> code, with support for printing, audio, file transfer between remote
>> and local parts, and so on.
>
> Wow, cool.
>
>> How do you plan to implement printing tunneling?
>
> Honestly, we haven't thought that far ahead just yet -)
I am not aware of your roadmap yet, however I can provide you with
some insight. Or even start to work in parallel. And hey, this is just
a suggestion and by no means I intend to run over anybody.
>
>> Should you wish, I would be please to help you. I believe we have
>> undergone many problems you might run into. Hence, feel free to take
>> on me.
>
> Great to have you around!
Always a pleasure.
Rafael
Michel van Horssen
> Hello,
Hi,
> How do you plan to implement printing tunneling?
> Should you wish, I would be please to help you. I believe we have
> undergone many problems you might run into. Hence, feel free to take
> on me.
2X -> FreeNX) we are having trouble with printing to remote locations
and it eating up bandwidth.
Could you tell us, or me in a PM, how your company solved this
problem? It would help us a lot until the time Neatx is production
ready and with printing tunnelling.
Thnx very much in advace.
Kind regards,
Michel
Rafael Roquetto
system, internally called rmprint. One of FreeNX maintaners, Fabian
Franz, works for us and has taken part on the development of this
subsystem, therefore, please make sure you either talk to him or check
FreeNX source code repository, if you need to grab the code. I don't
think upper management will allow the development team to license
current version, though. However, nothing much has changed, and I will
provide you with an onverview on how we do it:
On the server side, we have the following components:
- rmprintc
- rmprintmgr
- rmspool (optional)
On the client side we have
- rmprintd
Upon session initialization, server side connects to rmprintd
client-side daemon. It first requests a list of available printers,
alongside with their PPD files. If the host system is Microsoft
Windows, the PPD file is generated on-the-fly based on printer
information obtained thru the Win32 API itself.
When the server side receives this list of printers (this is
rmprintmgr we are talking about here), it installs then to current
users own CUPS instance. rmprintmgr then asks rmprintd for the default
printer, and sets it with CUPS as well. This marks the end of the
printing system init process. Oh yeah, all these printers are
associated with rmprintc backend.
When user prints something, rmprintc backend is activated. It expects
a PostScript stream as an input. It then renders the PS to PDF, and
passes this to the client (rmprintd), alongside with printing options
(Number of copies, shelf, etc). Rmprintd then submit the newly
received PDF to the printer spool, either to local CUPS server or to
the Windows spooler, depending on the host OS.
Last month we requested to implemented a printer "spooler". This is
actually an UI which mimics windows spooler, so users can check the
status of their submitted jobs. The spooler (rmspool), is spawned by
rmprintc, and polls rmprintd for jobs and information.
So, to summarize:
- On the client side, we have this daemon, rmprintd. It implements a
custom protocol, and handles everything related to printing, from
printer enumeration, spooler information and job submitting.
- On the server side, we have rmprintmgr - handles new printers, and
syncs with rmprintd. Install or removes printers to remote CUPS
server.
- rmprintc is the CUPS backend, expects a PS and outputs a PDF
alongside with other useful info.
- rmspool is the "spooler" UI.
I hope this is useful for you. Should you have any questions, please
do not hesitate to ask, and I will be pleased to help you.
Regards,
Rafael
Michel van Horssen
Hi Rafael,
First of all, thank you for your quick response and answer.
> I believe FreeNX actually implements an early version of our printing
> system, internally called rmprint. One of FreeNX maintaners, Fabian
> Franz, works for us and has taken part on the development of this
> subsystem, therefore, please make sure you either talk to him or check
> FreeNX source code repository, if you need to grab the code.
earlier post. Slipped my mind :)
> I don't
> think upper management will allow the development team to license
> current version, though. However, nothing much has changed, and I will
> provide you with an onverview on how we do it:
> On the server side, we have the following components:
So this is a use case for , lets say, someone working at home with a
fat client and one or more printers active in the local print manager
(cups or windows spooler). The client passes these printer onto the
printmgr and printc takes the exploded PS printjob and transforms it
to a pdf wich is send to the client which explodes it back to be
printed. :)
Those printers are for that session aka fatcient at that time.
> I hope this is useful for you. Should you have any questions, please
> do not hesitate to ask, and I will be pleased to help you.
for a lot locations connected over xdsl lines. At the location the
situation is as follows.
There is an DHCP/Tftpboot server on BSD (soekris), thinclients get a
thinstation image. Once loaded the nx client is started and the users
logs on to the terminal server at our central location. The printer is
a network printer which is known on the FreeNX server.
If we were to implement your solution in the thinstation image we
would need to put all known printers in it and the default printer for
that specific client. That would be a huge administrative task. Other
then that, spooling would take place on the thinclient and this would
mean a lot of extra memory is needed. Or not?
Another idea would be to try and implement such a thing on the
mentioned soekris. But even if we could, then we would have a problem
because if I understand you correct the printers are on a per session
base, so only the connected user would see those printers and not al
the thinclients in the local network.
Maybe I'm thinking to difficult. :) I don't think this will help us
with our bandwith consuming printing problem. :0
> Regards,
> Rafael
Thnx,
Michel
Rafael Roquetto
I am not sure if I got it right. Are the printers connected to the
FreeNX server, or to the clients (thin stations)?
In case they are connected to the FreeNX server, then our solution
does not make sense. We do have thin clients, but printers are
connected to them, or in the same local area network. As I can see,
you are doing exactly the opposite, i.e., you want your NX users to be
able to see printers connected to NX server (as opposed to have NX
server see local users printers). Am I right?
>
> If we were to implement your solution in the thinstation image we
> would need to put all known printers in it and the default printer for
> that specific client. That would be a huge administrative task. Other
> then that, spooling would take place on the thinclient and this would
> mean a lot of extra memory is needed. Or not?
I see it now. Your NX server operates locally (i.e. in the customer's
site), right? In our case, all of our servers are located on a data
center elsewhere, and we sell what people like to call cloud computing
(although I am sick of reading about it everywhere).
If your NX server is located on site, then it does make more sense to
have printers connected directly to them, at least at first sight,
imho. Then a simply default CUPS configuration should do the job.
Honestly, I think I am lost and missing the point, would you mind
trying to explain again? :)
>
> Another idea would be to try and implement such a thing on the
> mentioned soekris. But even if we could, then we would have a problem
> because if I understand you correct the printers are on a per session
> base, so only the connected user would see those printers and not al
> the thinclients in the local network.
>
> Maybe I'm thinking to difficult. :) I don't think this will help us
> with our bandwith consuming printing problem. :0
>
>> Regards,
>> Rafael
>
> Thnx,
> Michel
Rafael
Michel van Horssen
When I hit the send button yesterday I thought "Man, Rafael is
probably going to be confused" :)
I'll start again and just tell you what our situation is and maybe
then you can tell me if your printing solution can help or that there
maybe another one we overlooked.
We manage the IT for a lot of locations in the country. All FreeNX
servers are located in one data centre. We have xDSL lines on a
private network from all locations routing towards the data centre.
At any given location there is a soekris box managing dhcp and
tftpboot and one or more network printers. Also at a location there
are several thin clients (or fat ones acting as a thin client)
receiving a ThinStation image by tftp from the soekris box. A location
is just like any other normal office only without a central server and
the thinclients have a session on the FreeNX server at our data
centre.
The network printer at a location is known on the FreeNX server in the
data centre, it is not attached to the thin client.
So the NX session print to the cups spooler which sends it over the
xDSL line to the network printer at the location. Eating a lot of
bandwidth in the process. That bandwidth usage we would like to
compress or reduce so it doesn't interfere with the bandwidth needed
by the people working on the thin clients.
When you talked about tunnelling I thought it was NX server to printer
but it's NX server to local client.
Maybe we should be taking a look at cups <-> cups. Meaning the Cups
server on the FreeNX server in the data centre talking to a CUPS
server running on a small box (replacing the soekris) at the location
site spooling to the local network printer.
Thnx for telling me all about your solution, I'll keep it in mind for
any future project. If you know a better solution for our problem
please let me know.
Regards,
Michel
Rafael Roquetto
Sorry for taking so long to reply. I have been thinking about your
design, and in terms of network traffic, it does not change much when
compared to ours.
For instance, in your model: the user presses the print button, then
the document is rendered still on NX server, and finally is sent thru
the wire to the local printer.
Our model: the user presses the print button, then the document is
rendered to a PDF, and is also sent through the wire to the local
printer. The only difference is that our printers are logically
attached to the client endpoint (i.e. it could still be configured as
a remote printer, yet still logically a local printer), and yours is
not.
I think what you could do in order to reduce bandwidth usage is
implementing some sort of compression, such as bzip2. This is going to
require you a little bit of work, but basically what you should do is
develop a CUPS backend (could be in Perl or any scripting language
that you like), which expects a PS as input (this also dismisses the
requirement for having all of your printers drivers installed on the
server, you just need a Generic PS driver), and then converts it to
PDF for portability, and then compresses it to bz2 for instance, and
finally sends it thru the wire to a deamon running on your soekris
box.
This deamon will decompress the binary data, and spool the PDF to its
local CUPS spooler, and voi-la. Only the soekris box needs to have the
printer driver installed.
Also, it is important to note that, in case you decide to use this
approach, sending the PDF over the wire is not the only thing to be
done. Your protocol must support printer options, number of copies,
etc.
I am not sure whether this helps, and actually am clueless on how much
bandwidth is saved. Nonetheless, should you decide to take this
approach forward, I would be pleased to help you.
Regards,
Rafael