##IF_PRODUCT_44## ##IF_PRODUCT_45##

Rimage System Networking

Ease of use through networking


Most people work with the Rimage system through the use of a keyboard and mouse connected directly to an embedded Rimage system, or to the computer that is connected to a non-embedded Rimage system. However, there is another way, especially if you have more than one Rimage system added to a network. The Rimage Software Suite (RSS) is designed to be used across a network, and, unlike some minimalist client apps from competitive products, RSS provides you with the same great experience remotely as you get locally.



What can Rimage networking do for me?


If you have a network, you can do a lot more with your Rimage disc publishing system right from your own desk. For example, you could put Rimage Messaging Server on a server managed by your IT department, so it’s always available. You could take two Rimage systems and configure both to connect to this Messaging Server. Then, QuickDisc™ can be installed on your own computer at your desk. Meanwhile, the data for jobs can additionally be kept on a secure server that is backed up and has a lot of space. Now you can sit at your desk, submit a job to either Rimage system, and let the Rimage software retrieve the data right from your server.



How does Rimage software use the network?


The important part to know about Rimage software is that it utilizes XML messages via TCP/IP to communicate. Whether you’re submitting a job, checking the status of a job, receiving an out of discs alert or resetting the input bins, it is all XML messages. These messages are all handled by the Rimage Messaging Server, which operates on port 4664 by default. Every other component of Rimage software connects to Rimage Messaging Server to send and receive communication. So a client would send a job as XML to the Messaging Server, and then the Messaging Server would send it to an available Production Server. If there was an alert or job message, Production Server would send that back to Messaging Server to send to any clients listening for status.



While Messaging Server typically resides on a Rimage system itself, there is no requirement that it does. It can be installed on a remote server with redundancy and backup if needed. Additionally, multiple clients and Rimage systems can all refer to the same Messaging Server, allowing you to use one client to send a job to various Rimage systems, or a single Rimage System Manager application to monitor the production of all the Rimage systems on a network.



What about the job data itself?


While all Rimage communication is XML, the data to be recorded and label to be printed might also have to move across a network if it is not local to the Rimage system. RSS is designed to give you maximum flexibility in getting data to the Rimage system for recording, so there are a few potential ways to make this work. QuickDisc, the out of the box client for submitting jobs, use two different methods, while client applications might utilize even more.



The default method QuickDisc uses for job data uses the Rimage Stream Server. Custom applications created using our SDK may also use Stream Server. Stream Server is an application that runs on the client computer, and like QuickDisc, connects to Rimage Messaging Server to notify Rimage systems about its availability. Stream Server then listens on port 9613 of the client computer by default, utilizing the user credentials. If there are multiple users, each will have their own Stream Server, using incrementally higher port numbers to listen. When a job is submitted to a Rimage system, the Production Server on that Rimage system syncs to the Stream Server on the client and requests the job data. Since the Stream Server is running with the user credentials, it should have permission to receive access to all the same data for recording. Generally, no other permissions or networking is required to use this method, but some firewalls or security software on the client computer may block the Production Server from connecting to the client.

 



Another method QuickDisc uses is Windows File Sharing. In this case, QuickDisc will take the job data and copy it to the Rimage System Folder (RSF) on the Rimage system itself. When QuickDisc submits the job then, it uses the RSF folder as the path to the data in the job, so the Rimage system knows the data is already local. In this scenario, every user that wants to send jobs to the Rimage system would need to have write access to the RSF. The network also needs to allow standard Windows File Sharing.



The third method is the most common method for custom clients created using our SDK as well as sometimes being used by QuickDisc. This method utilizes UNC paths (Universal Naming Convention) in the job and requires Production Server to go out to the network to receive the data directly. This can create a few networking challenges to configure, but generally works quite well once it is set up. The Production Server on the Rimage system needs to be configured to have user rights on the network. Any data that will be recorded needs to be shared out with Windows File Sharing, and then the user that Production Server is configured with needs to be granted access to those shares. When a job is submitted, the paths to the data in the XML file will be the UNC path to the data on the share. Production Server then connects to the share to download the file as it is recording the disc.



What other networking does Rimage software use?


Other than the Messaging Server, Stream Server and Windows File Sharing, Rimage software may also use standard HTTP on default port 80. If you use the Rimage WebRSM™, WebQD™ or integrated using the WebServices SDK, you will be utilizing HTTP, as if browsing the web. If you point a web browser to the Rimage system, (e.g. http://RimageSystem) it will most likely bring up WebRSM because browsers also default to port 80.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Comments