Overview

Print Roaming is an extension of pull-printing. With pull-printing (also known as secured printing), after you send a print job to a printer, you later "pull" the job to a printer – that is, you go to a printer, log in there, and print the job. If Print Roaming is properly configured, you can pick up your documents sent to Dispatcher Paragon Server on every printer across all Spooler Controller groups.

Far Roaming

Far Roaming is (when a valid license is available) used among Spooler Controllers that are not part of any print cluster group (which is created automatically during installation of Dispatcher Paragon services) or among multiple Spooler Controller groups that have been created manually by the Dispatcher Paragon administrator.

How to disable Far Roaming in the Dispatcher Paragon system

1. Log into the Dispatcher Paragon management interface with sufficient rights to administer printers (for example, "admin"). Go to System > Configuration.
2. Switch to Expert mode.
3. Change the value of the enableFarRoaming configuration option to Disabled .

Near Roaming

There are two ways to configure Near Roaming Group – using a UDP (multicast) or TCP (unicast) connection.

1. Log into the Dispatcher Paragon management interface with sufficient rights to manage printers (for example, "admin"). Go to the Devices > Spooler Controllers groups section.
2. Click the Add Spooler Controller group button.
3. Enter the name of the new group – choose any name suitable for your needs (for example, "London branch roaming group", "Sales department", "Building A, 2nd floor", ...). Each group must have a unique name within the tenant scope.

4. TCP unicast vs. UDP multicast configuration

   It is strongly recommended to use UDP multicast instead of TCP unicast whenever possible. TCP unicast is sensitive to network temporary failures as opposed to UPD multicast, where the reliability of communication is achieved on higher network layers and provides less network load.

   Multicast communication in Dispatcher Paragon, as well as TCP Unicast, is provided via a third-party solution, industry standard communication Java technology called JGroups. JGroups technology extends reliable unicast (one-to-one) message transmission (as in TCP) to multicast (one-to-many) settings. It provides reliability and group membership on top of IP Multicast. It then enables you to use reliable multicast. Since every application has different reliability needs, JGroups provides a flexible protocol stack architecture. It allows you to put together custom-tailored stacks ranging from unreliable but fast to highly reliable but slower stacks.

   Unicast communication is where one sender sends a message to one receiver. TCP unicast takes care of message retransmission for missing messages, weeds out duplicates, fragments packets that are too big and presents messages to the application in the order in which they were sent. Then using TCP will cause additional network overheads caused by the nature of TCP. This, in turn, decreases the solution's scalability. Each additional member (node) added into a TCP cluster creates a significant amount of communication to the network due to point-to-point communication with other nodes in the cluster.

   In the multicast case where one sender sends a message to many receivers, IP Multicast extends UDP: a sender sends messages to a multicast address and the receivers have to join that multicast address to receive them. As in UDP, message transmission is still unreliable, and there is no notion of membership (who has currently joined the multicast address). The UDP Multicast configuration of Dispatcher Paragon is already set, out-of-the-box, to use reliable multicast. The only thing that needs to be done is to ensure that the infrastructure supports UDP Multicast communication among all Near Roaming group members (nodes).

   
   

   1. Near Roaming using TCP (preferred for small groups)

      Set the group as follows:
      Name: Any name suitable
      Multicast IP address: 0.0.0.0 (mandatory)
      Multicast port: 7800 (mandatory)

      IP address 0.0.0.0 and port 7800 have to be used when using TCP.

      The limitation of a TCP Near Roaming group: the maximum is 10 Spooler Controller servers in one group.

   2. Near Roaming using UDP Multicast

      Make sure multicast networking is allowed between all Spooler Controller servers in the Near Roaming group.

      Set up the group as follows:
      Name: any name suitable
      Multicast IP address: It is recommended to use an IPv4 address in the range 239.*.*.* This information shall be provided by the customer and has to reflect the current network setup.
      Multicast port: any UDP port in the range of 1 and 65535. This information shall be provided by the customer and has to reflect the current network setup.
      For more information, refer to http://en.wikipedia.org/wiki/IP_multicast

      Example of first group:

      Name: Beijing Sales dept.

      Multicast IP address: 239.214.54.87

      Multicast port: 9874

       

      Example of second group:

      Name: Athens HQ, 1st floor

      Multicast address: 239.214.54.87

      Multicast port: 9875
5. Create a new Spooler Controller or use an existing one and move it to the created roaming group.
   
   1. Select the Spooler Controller in the list to move and click the Edit button in the right column. Select any existing Spooler Controller group in the Print Cluster section. As soon as the value is changed, Save Changes and Discard Changes buttons appear at the bottom of the web page – click Save Changes.
   2. If you need to move more Spooler Controllers to a Near Roaming group, select all Spooler Controllers (using the checkbox next to each Spooler Controller) to move, click Actions in the upper-right section, click Move selected Spooler Controllers and select any existing Spooler Controller group from the list.
6. Follow the steps described in How and When to Restart a Standalone SPOC and SPOC Group to finish the procedure and let the SPOC group be fully operational (i.e., the distributed layer is started with the correct configuration and populated with users' data).