The following options can be edited in the JPIP configuration files on Windows and Unix, samples of which are included in The JPIP Configuration File.
-log <log file>
Redirects console messages to the specified log file.
-record
Print all HTTP requests and replies to stdout.
-version
Print core system version the server was compiled against.
-v
Abbreviation of `-version'
-usage
Print a comprehensive usage statement.
-u
Print a brief usage statement.
-history <max history records>
Indicates the maximum number of client records which are maintained in memory for serving up to the remote administrator application. Each record contains simple statistics concerning the behavior of a recent client connection. The default limit is 100, but there is no harm in increasing this considerably.
-port <listen port number>
By default, the server listens for HTML connection requests on port 80. To override this, you may specify a different port number here.
-address <listen IP address>
You should not need to use this command unless you wish to serve images from a multihomed host. By default, the server uses the first valid IP address on which the machine is capable of listening. IP addresses should be supplied in the familiar period-separated numeric format. To use this command following installation of the JPIP server, edit the JPIP configuration File (see The JPIP Configuration File).
-delegate <host>[:<port>][*<load share>]
Delegate the task of actually serving clients to one or more other servers, usually running on different machines. This argument may be supplied multiple times, once for each host to which service may be delegated. When multiple delegates are supplied, the load is distributed on the basis of the optional load share specifier. The load share is a positive integer, which defaults to 4, if not explicitly provided. Clients are delegated to the available hosts on a round-robin basis until each host has received its load share, after which all the load share counters are initialized to the load share value and round robin delegation continues from there.
-max_rate <max bytes/second>
By default, transmission of JPEG 2000 packet data to the client is limited to a maximum rate of 4 kBytes/second. A different maximum transmission rate (expressed in bytes/second) may be specified here. Data is transmitted at the maximum rate until certain queuing constraints are encountered, if any.
-max_rtt <max target RTT, in seconds>
Maximum value to be used as the server's target round trip time (RTT). The actual instantaneous RTT may be somewhat larger than this, depending upon network conditions. The default value for this argument is 2 seconds.
-min_rtt <min target RTT, in seconds>
Minimum value to be used as the server's target round trip time (RTT). The actual instantaneous RTT may be smaller than this value, but the server endeavors to queue sufficient messages onto the network so as to realize at least this RTT. The default value for this argument is 0.5 seconds. Whenever the minimum target RTT is lower than the maximum target RTT, the server will attempt to hunt for the smallest target RTT which is consistent with these bounds and also maximizes network utilization.
-max_chunk <max transfer chunk bytes>
By default, the maximum size of the image data chunks shipped by the server is 1024 bytes. Flow control at the server or client is generally performed on chunk boundaries, so smaller chunks may give you finer granularity for estimating network conditions, at the expense of higher computational overhead, and some loss of transport efficiency. In any event, you may not specify chunk sizes smaller than 128 bytes here. Values smaller than about 32 bytes could cause some fundamental assumptions in the kdu_serve object to fail.
-max_area <max samples in viewport>
By default, transmission of JPEG 2000 packet data to the client is limited to 16,777,216 samples, allowing viewports larger than most monitor sizes. (The formula used to determine this value is "requestWidth x requestHeight x numBands rounded to the next power of 2"). A different viewport size limit may be specified here. The number expresses the maximum number of component samples that the client can ask for in one request. Setting this value lower may be desirable to prevent very large requests from overloading network bandwidth. Setting this value higher may be desirable to allow single large high-resolution requests.
-time <max connection seconds>
By default, clients will be automatically disconnected after being continuously connected for a period of 5 minutes. A different maximum connection time (expressed in seconds) may be specified here.
-clients <max client connections>
By default, the server permits two client connections to be serviced at once. This argument allows the limit to be adjusted.
-sources <max open sources>
By default, the server permits one open JPEG 2000 source file for each client connection. This argument may be used to reduce the number of allowed source files. Clients browsing the same image share a single open source file, which leads to a number of efficiencies. New client connections will be refused, even if the total number of clients does not exceed the limit supplied using the -clients option, if the total number of open files would exceed the limit. If the -clients argument is missing, the value supplied to a -sources argument also becomes the maximum number of connected clients.
-initial_timeout <seconds>
Specifies the timeout value to use for the handshaking which is used to establish persistent connection channels. Each time a TCP channel is accepted by the server, it allows this amount of time for the client to pass in the connection message. In the case of the initial HTTP connection, the client must send its HTTP GET request within the timeout period. In the case of persistent TCP session channels, the client must send its initial CONNECT message within the timeout period. The reason for timing these events is to guard against malicious behavior in denial of service attacks. The default timeout is 5 seconds, but this might not be enough when operating over very slow links.
-completion_timeout <seconds>
Specifies the time within which the client must complete all persistent connections required by the relevant protocol, from the point at which it is sent the corresponding connection parameters. The server will not hold a session open indefinitely, since the client might terminate leaving the resources unclaimed. The default timeout value is 20 seconds.
-connection_threads <max threads for managing new connections>
Specifies the maximum number of threads which can be dedicated to managing the establishment of new connections. The new connections are handed off to dedicated per-client threads as soon as possible, but connection threads are responsible for initially opening files and managing all tasks associated with delegating services to other servers. By allowing multiple connection requests to be processed simultaneously, the performance of the server need not be compromised by clients with slow channels. The default maximum number of connection management threads is 5.
-cache <cache bytes per client>
When serving a client, the JPEG 2000 source file is managed by a persistent Kakadu codestream object. This object loads compressed data on demand from the source file. Data which is not in use can also be temporarily unloaded from memory, so long as the JPEG 2000 code-stream contains appropriate PLT (packet length) marker segments and a packet order in which all packets of any given precinct appear contiguously. If you are unsure whether a particular image has an appropriate structure to permit dynamic unloading and reloading of the compressed data, try opening it with kdu_show and monitoring the compressed data memory using the appropriate status mode.
Under these conditions, the system employs a FIFO (first-in first-out) caching strategy to unload compressed data which is not in use once a cache size threshold is exceeded. The default cache size used by this application is 2 Megabytes per client attached to the same code-stream. You may specify an alternate per-client cache size here, which may be as low as 0. Kakadu applications should work well even if the cache size is 0, but the server application may become disk bound if the cache size gets too small.
-wd <working directory>
Specifies the working directory for the Kakadu server; this can work in conjunction with the -restrict parameter if required.
-cd <directory in which to store ".cache" files>
The server creates a ".cache" file for each source file that it serves, which contains a digest of the metadata structure and the selected placeholder partitioning (see -phld_threshold). So long as the ".cache" file persists, the image will be presented in the same way to clients. This means that clients can reliably share information with each other and that a client may reconnect to an image at some later point (perhaps days or weeks) and fully reuse the information cached from previous browsing sessions. Once the ".cache" file is created, it will not be changed when clients later connect to the same image. By default, the ".cache" file is written to the same directory as the original image file. The present argument allows you to specify an alternate directory for the ".cache" files. The cache file's path name is formed by appending the requested image file name, including all relative path segments, to the supplied directory name. If the cache directory is specified with a relative path, that path is relative to the working directory, which may be explicitly specified via the -wd argument. This argument and the -wd argument are both most reliably used in conjunction with the -restrict argument.
-restrict
Restrict access to images in the working directory
-ignore_relevance
By supplying this flag, you force the server to ignore the degree to which a precinct overlaps with the spatial window requested by the client, serving up compressed data from all precincts which have any relevance at all, layer by layer, with the lowest frequency subbands appearing first within each layer. By contrast, the default behavior is to schedule precinct data in such a way that more information is provided for those precincts which have a larger overlap with the window of interest. If the source code-stream contains a COM marker segment which identifies the distortion-length slope thresholds which were originally used to form the quality layers, and hence packets, this information is used to schedule precinct data in a manner which is approximately optimal in the same rate-distortion sense as that used to form the original code-stream layers, taking into account the degree to which each precinct is actually relevant to the window of interest.
-phld_threshold <JP2 box partitioning threshold>
The threshold represents the maximum size for any JP2 box before that box is replaced by a placeholder in its containing data-bin, where the placeholder identifies a separate data-bin which holds the box's contents. Selecting a large value for the threshold allows all metadata to be appear in metadata data-bin 0, with placeholders used only for the contiguous codestream boxes. Selecting a small value tends to distribute the metadata over numerous data-bins, each of which is delivered to the client only if its contents are deemed relevant to the client request. The default value for the partitioning threshold is 32 bytes.
Note carefully that this argument will have no affect on the partitioning of metadata into data-bins for target files whose representation has already been cached in a file having the suffix, ".cache". This is done whenever a target file is first opened by an instance of the server so as to ensure the delivery of a consistent image every time the client requests it. If you delete the cache file, the server will generate a new target ID which will prevent the client from reusing any information it recovered during previous browsing sessions.
-rss_root <uri-path>
Specifies a base URL for retrieving OrderID RSS feeds.
-rss_debug
Enables some debug-mode features for OrderID RSS feeds, and allows the server to stream straight JP2/NITF files as well as XML feeds.
-catcfg
Used with the value auto to specify that the JPIP server runs in catalog mode rather than in absolute path mode. In catalog mode, the JPIP server reads the catalog configuration file (catalogs.xml) file to determine where a catalog is defined and then builds the path based on that definition. Thus, you can enter a request URL composed of the catalog name and the item name. For example:
jpip://<server>:<port>/<catalogName>/<itemName>.jp2
If this option is missing from the JPIP configuration file (jpiphost.exe.config), the absolute path to the image must be specified in the request for the image. For example:
jpip://<server>:<port>/<full_path_to_file>.jp2
The HTTP protocol (http://) will also work in both modes.
By default the -catcfg switch appears in the JPIP configuration file with a value of auto. To use absolute paths, delete this switch/value pair.
NOTE: In catalog mode, you must restart the JPIP server after adding a catalog.
| -initial_timeout | 60 |
| -completion_timeout | 60 |
| -time | 6000 |
| -max_chunk | 4096 |
| -max_rate | 999999 |
| -port | 9002 |
| -passwd | notTooCryptic |
| -wd | C:\jpipservice\wd |
| -log | C:\jpipservice\wd\kdu_serv.log |
| -cd | C:\jpipservice\cache |
| -rss_root | file:///c:/georss |