With modern switched Ethernet networks, bandwidth is rarely a factor when planning PaperCut NG/MF deployments. The bandwidth consumed by PaperCut NG/MF is usually dwarfed by the print document data - e.g. the Postscript spool data sent across the network. Bandwidth does, however, become a consideration when planning deployments crossing physical site boundaries such as networks linked via a WAN.
PaperCut NG/MF uses an XML based web services protocol for communication between client-to-server and server-to-server. This protocol is very bandwidth efficient and designed to work well on low bandwidth and high latency networks.
Bandwidth estimates
Bandwidth consumption can be summarized as follows:
Server-to-server
Other than normal print server traffic (standard job spooling), PaperCut NG/MF generates XML-RPC based Web Services based traffic on port 9191 (HTTP), 9192, 9195 (HTTPS). Connections are made from the print server to the main PaperCut NG/MF Application Server (primary server). Normal activity is around 1-2kb of traffic for each print job. Connections are instigated from the secondary server. Network packets are only sent during printing activity.
Client-to-server
Connections are instigated by the client inbound to the server on port 9191 (HTTP), 9192, 9195 (HTTPS). While at idle, the client consumes a few bytes once every minute (a keep-alive heartbeat). During print activity, up to 1-2kb per print job can be consumed depending on client popup settings.
If using account selection popups, the client must download the latest account list from the server whenever it is updated. The accounts are downloaded in a very efficient compressed format (approximately 20 bytes per account). If you have 10’s of thousands of accounts, and many clients running on remote sites with limited bandwidth, see Manage large client billing databases .
Comments