Uniprint & Blueprint: How Printer Ports and Port Monitors are used within the Windows Spooler.

Question:

How ports and port monitors are used within the Windows Spooler. 

Information:

In almost any operating system, a printer object always has a port defined. This port tells the operating system where to send the job. In Windows, a port is controlled by a Port Monitor. The port monitor's job is to accept the job from Spooler and then repackage it for transmission. Common network port monitors include TCPMON.DLL (the Standard TCP/IP Printing port type) and LPRMON.DLL (for the LPR port). Every port monitor, whether provided as part of the Windows operating system or by a third party (like our Secure Release Service port monitor), all have one fundamental limitation: a port can only service one print request at a time. So on a busy queue, jobs can tend to stack up, and are eventually all released to their destination. Beginning in Windows NT 3.5.1, Microsoft introduced the concept of "pooling" ports within a single queue instance. It was originally developed as a way to load balance printers: one queue would have some ports pooled together, and each individual port had a physical device waiting on the other end. A user would print a job and Spooler would randomly select one of the pooled ports for the destination. The caveat was that your printers had to be co-located, or you might never find your output.

There was a side benefit to pooling. A single queue object could now handle as many simultaneous jobs as it had pooled ports. We took advantage of this feature when developing our Secure Release Here operation. The Secure queue would be defined with 10 pooled ports monitored by our Secure Port Monitor, which connected with the Secure Release Service. So we can handle 10 simultaneous (or near simultaneous) print requests and avoid most opportunities for backlog. However, it is still possible to get a backlog:

1. A large print file occupies the "PS5" port for a very long time whilst the client spools it to the server. This event can be additive.

2. The print driver performs an operation on each inbound job (converting from EMF to the RAW format supported by the driver; PostScript or PCL, for example).

3. The driver manages a process that is taking too long.

4. The hard disk or hard disk controller hosting the SRH "JobStore" folder may be experiencing performance issues (disk queuing, for example). This can happen a lot on a SAN, and even worse if the drive is actually a mapped space from a NAS system.

5. There is a general resource condition and the Spooler cannot handle the inbound requests fast enough.

These are just a few of the examples. As long as the jobs continue to move through, albeit at  slower pace than hoped for, there's usually no cause for alarm. The customer may desire to split the load up by creating an alternate SRH queue. This will effectively double (or triple, depending on how many queues are added) the simultaneous job handling. Some sites have requested that we add more than 10 secure ports to a queue. Unfortunately, when this has been implemented, there's a point (not too far from 10) where we experience diminishing returns and the system is actually more slothful than before the change. We don't recommend this practice of increasing the pooled ports, though Windows has no published limit to the number of ports that can be pooled.