This RPC is used to start image acquisition (scanning).
| request: | reply: |
| SANE_Word handle | SANE_Status status |
| SANE_Word port | |
| SANE_Word byte_order | |
| SANE_String resource |
In the reply, argument resource is set to the name of the resource that must be authorized before this call can be retried. If this value is non-NULL, all other arguments have undefined values (see Section 5.2.10 for details on how to authorize a resource). Argument, status indicates the completion status. If the value is anything other than SANE_STATUS_SUCCESS, the remainder of the reply has undefined values. The argument port returns the port number from which the image data will be available. To read the image data, a network client must connect to the remote host at the indicated port number. Through this port, the image data is transmitted as a sequence of data records. Each record starts with the data length in bytes. The data length is transmitted as a sequence of four bytes. These bytes should be interpreted as an unsigned integer in big-endian format. The four length bytes are followed by the number of data bytes indicated by the length. Except for byte-order, the data is in the same format as defined for sane_read(). Since some records may contain no data at all, a length value of zero is perfectly valid. The special length value of 0xffffffff is used to indicate the end of the data stream. That is, after receiving a record length of 0xffffffff, the network client should close the data connection and stop reading data.
Argument byte_order specifies the byte-order of the image data. A value of 0x1234 indicates little-endian format, a value of 0x4321 indicates big-endian format. All other values are presently undefined and reserved for future enhancements of this protocol. The intent is that a network server sends data in its own byte-order and the client is responsible for adjusting the byte-order, if necessary. This approach causes no unnecessary overheads in the case where the server and client byte-order match and puts the extra burden on the client side when there is a byte-order mismatch. Putting the burden on the client-side improves the scalability properties of this protocol.