summaryrefslogtreecommitdiff
path: root/docs/docbook/devdoc/printing.sgml
blob: 1d4085bb88ecb4f626ec128a5acef8eb13530b94 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
!=
!= Samba Printing Internals
!= 
!= Author : Gerald Carter <jerry@samba.org>
!=
!===================================================================

The purpose of this document is to provide some insight into
Samba's printing functionality and also to describe the semantics
of certain features of Windows client printing.

Print Queue TDB's
------------------

* matching lanman jobids, spoolss jobids, & lpd jobids
* why ?
* caching time


ChangeID & Client Caching of Printer Information
------------------------------------------------

[To be filled in later]


Windows NT/2K Printer Change Notify
-----------------------------------

When working with Windows NT+ clients, it is possible for a
print server to use RPC to send asynchronous change notification
events to clients for certain printer and print job attributes.
This can be useful when the client needs to know that a new
job has been added to the queue for a given printer or that the
driver for a printer has been changed.  Note that this is done 
entirely orthogonal to cache updates based on a new ChangeID for 
a printer object.

The basic set of RPC's used to implement change notification are

  * RemoteFindFirstPrinterChangeNotifyEx ( RFFPCN )
  * RemoteFindNextPrinterChangeNotifyEx ( RFNPCN )
  * FindClosePrinterChangeNotify( FCPCN )
  * ReplyOpenPrinter
  * ReplyClosePrinter
  * RouteRefreshPrinterChangeNotify ( RRPCN )

One additional RPC is available to a server, but is never used by the
Windows spooler service:

  * RouteReplyPrinter()

The opnum for all of these RPC's are defined in include/rpc_spoolss.h

Windows NT print servers use a bizarre method of sending print
notification event to clients.  The process of registering a new change
notification handle is as follows.  The 'C' is for client and the
'S' is for server.  All error conditions have been eliminated.

C:	Obtain handle to printer or to the printer
	server via the standard OpenPrinterEx() call.
S:	Respond with a valid handle to object

C:	Send a RFFPCN request with the previously obtained
	handle with either (a) set of flags for change events
	to monitor, or (b) a PRINTER_NOTIFY_OPTIONS structure 
	containing the event information to monitor.  The windows
	spooler has only been observed to use (b).
S:	The opens a new TCP session to the client (thus requiring
	all print clients to be CIFS servers as well) and sends
	a ReplyOpenPrinter() request to the client.
C:	The client responds with a printer handle that can be used to 
	send event notification messages.
S:	The server replies success to the RFFPCN request.

C:	The windows spooler follows the RFFPCN with a RFNPCN
	request to fetch the current values of all monitored 
	attributes.
S:	The server replies with an array SPOOL_NOTIFY_INFO_DATA
	structures (contained in a SPOOL_NOTIFY_INFO structure).

C:	If the change notification handle is ever released by the 
	client via a PCPCN request, the server sends a ReplyClosePrinter()
	request back to the client first.  However a request of this 
	nature from the client is often an indication that the previous
	notification event was not marshalled correctly by the server
	or a piece of data was wrong.
S:	The server closes the internal change notification handle 
	(POLICY_HND) and does not send any further change notification
	events to the client for that printer or job.

The current list of notification events supported by Samba can be 
found by examining the internal tables in srv_spoolss_nt.c

  * printer_notify_table[]
  * job_notify_table[]

When an event occurs that could be monitored, smbd sends a messages
to itself about the change.  The list of events to be transmitted 
are queued by the smbd process sending the message to prevent and 
overload of TDB usage and the internal message is sent during smbd's
idle loop (refer to printing/notify.c and the functions
send_spoolss_notify2_msg() and print_notify_send_messages() ).


The decision of whether or not the change is to be sent to connected 
clients is made by the routine which actually sends the notification.
( refer to srv_spoolss_nt.c:recieve_notify2_message() ).  

Because it possible to recieve a listing of multiple changes for 
multiple printers the notification events must be split into
categories by the printer name.  This makes it possible to group 
multiple change events to be sent in a single RPC according to the
printer handle obtained via a ReplyOpenPrinter().

The actual change notification is performed using the RRPCN request 
RPC.  This packet contains 

  * the printer handle registered with the client's spooler on 
    which the change occurred
  * The change_low value which was sent as part of the last 
    RFNPCN request from the client
  * The SPOOL_NOTIFY_INFO container with the event information
    - the version and flags field are predefined and should not 
      be changed
    - The count field is the number of entries in the 
      SPOOL_NOTIFY_INFO_DATA array
      o The type defines whether or not this event is for a printer 
        or a print job
      o The field is the flag identifying the event
      o the notify_data union contains the new valuie of the attribute
      o The enc_type defines the size of the structure for marshalling
        and unmarshalling
      o (a) the id must be 0 for a printer event on a printer handle.
        (b) the id must be the job id for an event on a printer job
	(c) the id must be the matching number of the printer index used
	    in the response packet to the RFNPCN when using a print server
	    handle for notification.  Samba currently uses the snum of
	    the printer for this which can break if the list of services
	    has been modified since the notification handle was registered.
       o The size is either (a) the string length in UNICODE for strings,
         (b) the size in bytes of the security descriptor, or (c) 0 for
	 data values.