Forum Discussion
Receiving notifications from universal print without firewall changes. Websocket ?
HimanJo the job notification subscription is a callback model so the URL needs to be reachable by the cloud service.
Are you able to look into hosting your application in the cloud?
Or, have a proxy that re-routes the incoming internet traffic into the local network so you only have to open port 443 or 80 which have well known methods for security lockdown/packet inspection.
HTH,
Jimmy
Jimmy_Wu Thank you so much for responding. However, I won't be able to host the application in the cloud nor have an intermediate proxy. This application is supposed to run on the printer which is beyond the firewall.
The problem that I am trying to solve is -
How would the physical printer know that a job has been submitted by the user and it needs to be fetched and printed?
In my case I don't want to use a connector but I need to write a program which runs on the printer and then fetches and prints the job after it has been submitted by the user.
Based on my knowledge, I can think of -
Notifications or would polling the virtual print queue for newer jobs (from the printer app) be a better approach ?
Thank you
HimanJo if the program runs on the physical printer, then you currently have 2 options.
- As you suggested, do a periodic poll against Universal Print using the registered printer's account to see if there's a print job for it.
- If you are familiar with IPP protocol, then you can create a event notification subscription based on RFC 3996 (RFC 3996 - Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications (ietf.org)). Basically, the program will connect to Universal Print as a long hanging 'get' and the connection is kept alive and gets a response when there's an event (such as print job available). The program is expected to connect back to Universal Print after a response so the next event can be sent. This way, the connection is established from behind the firewall out into the Internet so no firewall port opening is required.
The polling method will be easier to implement, but the overall print experience will need to be balanced between too many rapid poll requests (excess network traffic and power consumption) versus too long of a wait time between polls.
Hope that helps.
Jimmy_Wu .
Could you be more specific about keeping the connection as a get in the IPP protocol, specifically the Get-Notificaiton event. I don't know how to set the notify-wait = true (because it leads to the method hanging there)
