You'll remember that the AppSocket configuration form has a timeout field. The emulation also has a timeout field. For many printers, this seems to default to 15 seconds.
Finally, the job can also contain a timeout value in the PJL code.
RPM sets a timer for the longest period among these values: the default, the printer setting, and the job setting.
Once that period is up, RPM checks whether the job has received data. On the first check, the answer should be "yes, it has" unless the print job is empty. So, RPM starts another timer.
If we haven't received any new data in the next period, RPM closes the connection and submits the job.
To recap, RPM takes the largest of these three values:
- the default timeout in the AppSocket configuration form
- the default timeout in the printer emulation
- the timeout in the actual job itself
The job will typically wait approximately twice as long as the timeout value to close, assuming that the sending side does not close the connection during that wait.
If the sending side closes the connection, RPM submits the job immediately without any waiting involved. During our local tests, we see RPM handling 200 jobs or more per second, so we don't consider there to be a timeout penalty.