JPH06103186A - Gateway system - Google Patents

Abstract

PURPOSE:To effectively execute the connection management by protocol by managing the connection with a connection identifier and a connection type. CONSTITUTION:Computers 111 to 11n having a protocol FTP(file transfer protocol) or a protocol XNS (xerox network system), printers 121 to 12n having the protocol XNS, and gateway 10 having the both of the protocol FTP and the protocol XNS are on the same logical network 13. The gateway 10 is provided with three receptions of an FTP client section 14 as a file reception processing section, FTP server section 15, and XNS server section 16 and an XNS Printing client section 17 as the transmission processing section of a file. In this case, the gateway can available from the host directly requesting the printing for the printer, resulting in improving the connection of the host.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a gateway system for protocol-convertible data transfer between a plurality of devices having different communication protocols.

[0002]

2. Description of the Related Art Conventionally, in a network system in which a data processing device (host computer) and a printer having different communication protocols are connected on the same transmission medium, a multi-protocol for performing protocol conversion between different protocols, Various systems have been proposed for providing a gateway that supports multiple hosts and multiple printers. As a method of transferring a file from a host computer (hereinafter simply referred to as "host") to the gateway, the gateway acquires files on the host. To FTP (File Transfer Prot
ocol: File transfer protocol) having a client function (for example, Japanese Patent Laid-Open No. 4-155558), having an FTP server function of receiving a connection request from the host and receiving a file in addition to the FTP client function (for example, , Japanese Patent Laid-Open No. 3-75949). There is also known a technique in which a host having a different communication protocol sends a print request file to a printer control device by each protocol, and the printer control device performs protocol conversion (for example, Japanese Patent Laid-Open No. 63-47174). There is also a technique of managing a connection by setting a connection identifier that uniquely identifies the connection when the processing device establishes a connection with another data processing device through the communication control device (for example, Japanese Patent Laid-Open No. 3-30083). No. 113660).

[0003]

In the conventional system (Japanese Patent Laid-Open No. 4-155558) in which a gateway acquires a file on a host only by the FTP client function, a request for opening a connection from the host side can be accepted. There was an inconvenience that I could not do it. The connection was determined and managed by the host identifier and the spool identifier. On the other hand, the FTP
In the system having both the client function and the FTP server function (Japanese Patent Laid-Open No. 3-75949),
Although the connection opening request from the host of the communication protocol FTP can also be accepted, the connectivity is improved, but it is necessary to consider the connection type in addition to the above-mentioned host identifier and spool identifier for managing the connection. Therefore, connection management was complicated. Also, in these conventional systems, when exchanging requests / data between the gateway and the printer,
First, a connection (communication path) is opened in the lower layer (network layer) of the OSI 7 layer, data in the upper layer is exchanged using the connection, and the connection is always released when the data exchange is completed. With this method, when data is frequently exchanged, a connection must be opened / released every time, and efficient data exchange cannot be performed. Further, although it has been widely practiced in the past to directly transmit to a printer by a communication protocol supported by the printer such as a communication protocol XNS without providing the gateway as described above, the spool area of the printer is used. However, the print request acceptance may be influenced by the limitation of the printer, the restriction on the number of connections that can be connected to the printer at the same time, and the fact that no print request can be made when the printer is down.

An object of the present invention is to solve the above problems. That is, it is an object of the present invention to obtain a gateway system capable of efficiently managing connections between various devices on a network according to various protocols. Another object of the present invention is to obtain a gateway system which can improve the efficiency of exchange when data is exchanged frequently. It is another object of the present invention to provide a gateway system capable of receiving a request without being influenced by the state of the printer even when a print file is transmitted from a host using a communication protocol supported by the printer.

[0005]

The present invention (Claim 1) includes:
Multiple devices with different communication protocols (11 _{1 in} FIG. 1)
Respect to 11 _n, 12 ₁ to 12 _m) common transmission medium is connected (13 in FIG. 1) are connected by a single interface, gateway system for protocol conversion enables data transfer between these plurality of devices (10 in FIG. 1) is a gateway system provided with first management means (18 in FIG. 1) for managing each connection to the device by a connection identifier and a connection type.

Further, according to the present invention (claim 2), in the gateway system, second management means for delaying the release of the connection when there is a next processing request within a predetermined time after the connection is established ( 2 of FIG.
67, 268) may be provided.

Further, the present invention (claim 3) provides a plurality of devices (11 _{1 to} 11 _n and 12 _{1 to} 12 _{m in} FIG. 1) having the different communication protocols in the gateway system.
Includes a printer that supports a certain communication protocol (XNS) (12 _{1 in} FIG. 1) and a data processing device (11 _{n in} FIG. 1) that can make a print request using the communication protocol supported by the printer. And
The gateway system includes means (15 in FIG. 1) for receiving a print request according to the communication protocol supported by the printer, and means (17 in FIG. 1) for transmitting the received request to the printer according to the communication protocol supported by the printer. The configuration may be provided.

[0008]

According to the present invention (Claim 1), the first managing means manages the connection by the connection identifier and the connection type. The connection identifier is, for example,
For the FTP client function, a pair of host name and spool name is assigned. For the FTP server function and the XNS server function, a pair of host name and user name is assigned for each type of connection. There is. Further, in this example, when the connection is established, the above-mentioned connection identifier is obtained from the pair of the host name and the user name, an access check is performed, and thereafter, information regarding the connection is acquired based on the connection identifier. As described above, since the connection management is performed based on the connection identifier defined for each connection type, the connection management can be efficiently performed in the gateway that handles a plurality of protocols.

According to the present invention (claim 2), a second
Management means delays the release of the connection when a next processing request is made within a predetermined time after the connection is established. Therefore, when data is frequently exchanged, the connection once opened can be used many times without being terminated, and the data can be efficiently exchanged.

Further, according to the present invention (claim 3), since the means (XNS server function) for accepting the print request by the communication protocol supported by the printer is provided,
The gateway can be used even from the host that made a print request directly to the printer,
Connectivity is improved. Also, by accepting print requests via the gateway in this way,
The print request acceptance is no longer restricted to the printer side such as the spool area limitation of the printer, the connection limitation that can be connected to the printer at the same time, and the inability to accept when the printer is down.

[0011]

【Example】

(First Embodiment) FIG. 1 schematically shows the construction of the first embodiment of the present invention. Protocol FTP (File
Transfer Protocol) or protocol XNS (Xerox Network System)
m), a plurality of host computers (hereinafter, simply referred to as “hosts”) 11 _{1 to} 11 _n , protocol XNS
A plurality of printers 12 _{1 to} 12 _n each having a printer and a gateway 10 having both a protocol FTP and a protocol XNS are present on the same logical network 13 and configured. The gateway 10 includes an FTP client unit 14 and an FTP server unit 1 as a file reception processing unit.
5, the XNS server unit 16 has three ports, and the XNS Printing client unit 17 is provided as a file transmission processing unit. There is also a spool 19 for temporarily storing the received file.

First, the outline of file transfer will be described.
There are three types of connections for file transfer from the host to the gateway. (1) A connection by the FTP client unit 14 in which the gateway explicitly acquires a file on the host using the communication protocol TCP. (2) A connection by the FTP server unit 15 that receives a file sent from the host using the communication protocol TCP. (3) A connection by the XNS server unit 16 that receives a file sent from the host using the communication protocol XNS.

FIG. 2 shows the data flow in the (1) th connection. Hosts, printers, and gateways exist on the same logical network system. Indicates a file transmission from the host to the printer on this network system. The gateway (FTP client unit) connects to the host by FTP (file transfer protocol), and periodically checks whether or not there is a print request file by the FTP NLST command. FTP R if the host has a print request file
Issue an ETR command and receive the file to the gateway spool directory. The gateway (XNS Printing client part) XNs the files in the spool directory.
Send to the printer using the S Printing protocol.

FIG. 3 shows the data flow in the connection of (2) or (3). The FTP host (or XNS host) sends the file to the gateway. The gateway sends the file in the spool directory to the printer by XNS Printing (printing protocol).

FIG. 4 is a diagram showing the functions relating to the connection of the gateway in this embodiment. That is, this gateway is, as shown in FIG. 4, a connection information file storage unit 4 for storing connection information for managing hosts and printers connected on the network.
1, a management unit 42 that manages connections based on the contents of the connection information file stored in the connection information file storage unit 41, an FTP connection reception processing unit 43 that performs connection reception processing for each connection type, and an XNS connection. Reception processing unit 44,
The spool connection reception processing unit 45 is included.
The connection information file storage unit 41 includes a spool connection information file 411, an FTP connection information file 412, and an XNS connection information file 41.
3 and the printer connection information file 414 are stored. The management unit 42 reads the connection information files in the connection information file storage unit 41 into the memory 422 at the time of initialization, and the file reading unit 421.
And a memory 422 for storing information, a memory reading unit 423 for reading the contents of the memory 422, an access check unit 424, and an information acquisition unit 425. F
The TP connection reception processing unit 43, the XNS connection reception processing unit 44, and the spool connection reception processing unit 45 are respectively the FTP server unit 15 and the XNS of FIG.
It corresponds to the functions of the server unit 16 and the FTP client unit 14.

The four files in the connection information file storage unit 41 store the following information, respectively. (1) Spool connection information file 411 The spool connection information file 411 describes host information used in the spool connection (FTP client function). FIG. 5 shows an example of the description format of the spool connection information file 411 and a description example. In this description example, the spool connection information file 411 contains / etc / gw / hos
The file name ts is given and two hosts are registered. The first entry has the host name acos
77, the host type is ACOS6, the user name when logging in to the host is nakazawa, the password is nakazawa, the account is toshi, and the directory name where the file is stored is / FXSPO.
OL, filename1 is used as the file name information name, and printer_a is used as the printer assignment information name.
Indicates that sign2 is used. The file name information is stored in the file name information file, and the printer assignment information is stored in the printer assignment information file, which will be described later.

(2) FTP Connection Information File 412 The FTP connection information file 412 describes the host: user who uses the FTP connection (FTP server function). FIG. 6 shows an example of the description format of the FTP connection information file 412 and a description example. In this description example, the FTP connection information file 412 contains / etc / gw / fthosts.
The file name is given, and three sets are registered in "host + user" units. In the first entry, "host name + user name" is "chariot + naka"
file ”as file name information
1 is used as the printer assignment information name print
Indicates that r_assign1 is used.

(3) XNS Connection Information File 413 The XNS connection information file 413 describes the host: user who uses the XNS connection (XNS server function). FIG. 7 shows an example of the description format and description example of the XNS connection information file 413. In this description example, the XNS connection information file 413 contains / etc / gw / xnhosts.
The file name is given, and two sets of "host + user" units are registered. The address of the first entry is 00001cf7: 0800200001cf
7. "Host name + user name" is "VAX780 @ 1 + v
axtaro ”and filena as file name information
me1 is used and printer is assigned as the printer information name
Indicates that ter_assign1 is used.

(4) Printer Connection Information File 414 The printer connection information file 414 describes printer information in the printer connection (XNS client function). FIG. 8 shows an example of the description format of the printer connection information file 414 and a description example. In the description example of this file, / etc / gw is set in the printer connection information file 414.
A file name of / printer is given and four sets of printers are registered. The first entry has a printer name of 6790 lps1 and a printer type of 67
90LPS, address is 00001cf7: 08003
7002939 is shown.

The above-mentioned file name information file and printer assignment information name file have the following functions. a) File name information file In the format shown below, the character of the file name (from the beginning to the character of the file name) is used as the class name for grouping printers. Describe in the name information file. filename1: 1: 2-7 filename2: 1-2: 3-7 In this example, filename1 uses the first character of the file name as class information and the second to seventh characters as a character string of the file reception order. Means Similarly, filename2 means that the first to second characters are used as class information and the third to seventh characters are used as a character string in the file reception order.

B) Printer assignment information name file Here, 6790 lps 1, 6790 lps 2, 67
There are four printers named 90lps7 and 6790lps9, and a concept of class is prepared for grouping the printers. Describe the correspondence between the class name and the printer name (= printer assignment information) in the printer assignment information file. FIG. 9 shows an example of the class definition file. File name information and printer assignment information are "host + user" in each server / client function.
Alternatively, it can be set in units of "host + directory".
In the example of the FTP connection information file that describes the connection host in the FTP server function of FIG. 6, the first entry "chariot + nakazawa" uses filename1 as file name information and class1 as printer assignment information. In this case, fil
The first character of the file name is interpreted as class information as defined by name1, and B is defined as transmitted as 6790 lps1 as defined by class1. For example, the first entry "chariot + na
The file "BTest" sent from "kazawa" is "Test" for the printer 6790lps1.
It means that the file is transmitted with a file name "t". FT
The same definition is applied to other functions such as the P client and the XNS server.

Next, the operation of this embodiment will be described.
The accessible host user is the information file for each connection type as described above, that is, the spool connection information file (file name / etc / gw / host).
s) 411, FTP connection connection information file (file name / etc / gw / fthosts)
412, XNS connection Connection information file (file name / etc / gw / xnhosts) 41
3 is defined in advance, and the printer connection on the transmission side is defined in the printer connection information file 414 and stored in the connection information storage unit 41. First, each connection information file 411
To 414 are stored in the memory 4 by the file reading unit 421.
Read in 22. At the time of reading, if a valid entry is described in the file, it is recognized as supporting the connection type, and the connection identifier (connection ID) is assigned in order from the described entry and expanded in the memory. To go. The connection ID in which the printer connection information on the transmission side is also described is assigned from 1 and expanded in the memory. FIG. 10 shows an example of expansion on the memory in the case of FTP connection information.
A connection ID is sequentially assigned to each entry.

FIG. 11 is a flow chart showing the outline of the receiving process for the connection request from the host to the FTP server function and the XNS server function of the gateway. When there is an FTP connection request from a certain host computer, the FTP connection reception processing unit 43 passes the request information to the access check unit 424 and requests an access check (step S111). Then, the access check unit 424
Refers to the FTP connection information file of the memory 422 to check whether or not the host user who made the connection request corresponds to the accessible host user (step S).
112). As a result, when the access is not possible, the access is denied (step S113). When it is determined that the access is possible, the access check unit 424 retrieves the corresponding connection ID from the memory 421 based on the host name and the user name of the connection connection request, and FT
It returns to the P connection reception processing unit 43. The FTP connection reception processing unit 43 obtains information about the required connection from the memory 422 using the connection ID as an argument via the information acquisition unit 425 (step S114). Then, a file reception process is performed (step S115). X
Even when there is an NS connection request, the access check is performed in the same manner as in the procedure of FIG. 11 and the acceptance process is performed.

Receiving process by the FTP client unit In the receiving process by the FTP client function of the FTP client unit 14, a receiving process is generated for each connection of the FTP connection information, and a host name and a user name are obtained to connect. FIG. 12 is a diagram showing a processing flow of the FTP client function. The FTP client 14 of the gateway makes a request to establish a connection for file transfer to the host, and when the request is accepted, establishes a connection for file transfer (step S121). Then, the user logs on to the host (step S122). This allows you to work with files on the host. Next, the directory change command cd is used to move from the root directory to the spool directory (step S123). And F
The TP client unit 14 issues a command NLST to check whether there is a file (reception file) for which a reception request is made in the spool directory (step S12).
4). If there is a received file as a result of the check, FT
The P client unit 14 issues the command RETR, receives the file, and stores it in the spool 19 (step S126). If there is no received file as a result of the check, wait for a certain period of time, and step S124
To the top (step S125). With respect to the received file, it is checked whether the file on the host should be deleted immediately after the reception (step S127). If the result of the check is Yse, the file in the spool directory on the host is deleted (step S128).
If the result of the check is No, it is checked whether all files have been received (step S129). If No, that is, if there is a file that has not been received yet, the process proceeds to step S126, and the reception of the file is continued. In the case of Yes, that is, when all the files have been received, the process returns to the process of step S124 and waits.

Reception Processing by FTP Server Unit As described above with reference to FIG. 11, the FTP connection is a process that is generated in the FTP server unit 15 when there is an FTP connection request from the host. After the FTP connection is established, the FTP server unit 15 sends the FT sent from the host.
Process P command. When the host sends a print job to the printing system using the FTP connection, the FTP command STOR is used. The command format is 1) STOR / printer_name / fil
e_name 2) STOR file_name 3) STOR / class_name / file_
There are three types of names. 1) is a method of designating a desired printer name for output. 2) is a method of designating an output printer by incorporating a printer designation character which is defined in advance in a file name. 3) is a method of designating a desired printer by designating a class designation character which is defined in advance. ST, which is a command representing transmission in the FTP command
The flow of a series of processing using the OR is shown in FIGS. 13, 14 and 15. As shown in FIG. 13, server initialization processing (step 1301), host check for checking whether the host used is registered in the authorization file (step S1)
302) is performed, and if the check is not passed, an error response code is returned (step S1303). When it passes, a response code indicating that the FTP connection is normally completed is returned (step S1304), and the process of the command is started. Note that these steps can be performed by the connection management described with reference to FIG. Prior to STOR, another FTP command, that is, a USER process for performing a process related to the USER of the FTP command (step S1305),
PASS that performs processing related to PASS of FTP command
Process (step S1306), STR of FTP command
STRU processing for performing processing related to U (step S130
7), M which performs the process related to the MODE of the FTP command
ODE processing (step S1308), TYPE processing for performing processing related to TYPE of FTP command (step S)
1309) and the PORT process (step S1310) for performing the process related to the PORT of the FTP command, but the contents of these commands are well known and will not be described. The STOR process (step S1311) that performs the process related to the STOR of the FTP command will be described in detail with reference to FIGS. 14 and 15.

First, the FTP server unit 15 checks in FIG. 14 whether or not reception is permitted (step S14).
01), if there is no reception permission, an error response code is returned (step S1402). If the reception is permitted, it is checked whether the spool area is in an unusable state (step S1403), and if it is, an error response code is returned (step S140).
4). When the spool area is free and available, the argument part of the STOR command is checked to determine whether it specifies a printer, a file name, or a class ( Step S
1405). If you specified a printer,
An internal file name is acquired from the printer name (step S1406). In this case, as described above, STOR / printer_name / file_n
It is a command of the form ame, and the argument printer_na
The internal file name can be obtained from me and file_name. As a result of the judgment, when the file name is designated, the internal file name is acquired from the file name (step S1407). In this case, as described above, the command is in the format of STOR file_name and its argument file_n
Characters for designating a printer are incorporated in specific predetermined positions of the character string ame, and the designation information is described in the file name information file as described above. The printer name is determined by obtaining the position of the printer designation character from the file name information file, and file_
The internal file name can be obtained by obtaining the file name from the remaining characters of name. For example,
When the file name information file describes that the fifth character of the character string of file_name is a character that specifies the printer, if file_name is AAAABA, the printer name is determined from character B and the remaining characters AAAAA. You can determine the file name from and get the internal file name from them. If the result of the determination is that the argument part of the STOR command specifies a class, the internal file name is acquired from the class name (step S1408). In this case, as described above, STOR / class_name / file_nam
The command is in the form of e, and the printer name can be determined by referring to the printer assignment information name file as shown in FIG. 9, so that the internal file name can be acquired.

Next, it is checked whether the file is a reception target file (S1409). This is done by, for example, defining a class not to be retrieved in the class definition of the printer assignment information name file, and checking whether or not it corresponds to this. If the check result indicates that the file is not the reception target file, an error response code is returned (step S1).
410), if the file is a reception target file, the file is opened (step S1411). If the file could not be opened, an error response code is returned (step S1412). When the file is opened, print data from the host is received (step S141).
3) It is checked whether the print data has been normally received (step S1414), and if the reception is unsuccessful, the file is closed and the received file is deleted (step S1).
415), an error response code is returned (step S141).
7). When the print data has been normally received, the file is closed (step (S1416). Next, similarly to step S1405, printer specification, file specification, or class specification is performed according to the format of the STOR command. Is determined (step S141
8) If the printer is designated, the received file is queued using the printer name (step S1419),
If the file is designated, the file name is used for queuing (step S1420). If the class is designated, the class name is used for queuing (step S1421).
If the queuing ends normally, a normal end response code is returned (step S1424), if the queuing fails, an error response code is returned (step S1423), and the received file is deleted (step S142).
5).

The FTP server unit 15 also has a function of obtaining a detailed list of print jobs using the FTP connection. In this case, the FTP command LIST command is used. The command format is 1) LIST 2) LIST / printer_name 3) LIST / printer_name / fill
There are three types of e_name. 1) is a method of obtaining a detailed information list of all printers connected to the printer system. 2) is a method of obtaining a detailed information list of print jobs queued in the designated printer. 3) is a method of obtaining detailed information of a designated printer and a designated print job name. 16 and 1 show the flow of a series of processing using LIST.
7 shows. As shown in FIG. 16, it is necessary to execute other FTP commands prior to the LIST processing.
Since the function of the P command is well known, its explanation is omitted. In FIG. 17, first, it is checked whether or not there is an argument of the LIST command (step S1701). As is clear from the above command format, if there is no argument, it is specified to obtain a detailed information list of all printers connected to the printer system, and therefore a status list of all printers is created (step S1702). . Then, the registered class name lists are merged (step S170).
3). If there is an argument, it is checked whether the printer designation of the first argument is correct (step S1704),
If not, an error response code is returned (step S1).
717). If the printer designation is correct, a list of print jobs queued in the designated printer is created (step S1705). It is checked whether or not there is a second argument (step S170).
6). If there is a second argument, the details of the designated print job among the print jobs queued in the designated printer are obtained as described above, and therefore the list created in step S1705 is designated with the second argument. The designated print job name is used as a key to search (step S1707). If the file specified in the argument is not found as a result of the search, an error response code is returned (steps S1708, 1717). Step S170
3, the file of the list obtained in step S1705 or step S1707 is opened (step S
1709). When the file can be opened, the file contents are transmitted (S1713). When the transmission is normally completed, a normal completion response code is returned (step S1716). If the transmission fails, an error response code is returned (step S171).
5).

The print job name can be obtained by the FTP server function of the FTP server unit 15. In this case, the FTP command NLST command is used. The command format is as follows: 1) NLST 2) NLST / printer_name 3) NLST / printer_name / fill
There are three types of e_name. 1) is a method of obtaining the names of all printers connected to the printer system. The method 2) is a method of obtaining a list of names of print jobs queued in the specified printer, which are sent by the host and the user and are queued in the spool queue of the printer. 3) is a method of obtaining a name list of designated printers and designated print job names (search using a wild card is possible). A series of processing flow using NLST is shown in FIG. 18 and FIG.
9 shows. As shown in FIG. 18, it is necessary to execute other FTP commands prior to the LIST processing.
Since the function of the P command is well known, its explanation is omitted. In FIG. 19, first, it is checked whether or not there is an argument of the NLST command (step S1901). As is clear from the above command format, if there is no argument in the NLST command, it is specified to get the names of all printers connected to the printer system.
A list of class names is created (step S1902). If there is an argument, it is checked whether the printer designation of the first argument is correct (step S1903), and if it is not, an error response code is returned (step S191).
5). If the printer designation is correct, a print job list queued in the spool queue of the designated printer is created (step S1904).
Next, it is checked whether or not there is a second argument (step S1905). If there is a second argument, the local host queued to the specified printer as described above,
Since the list of names of print jobs sent by the user and queued in the spool queue of the printer is obtained, the list created in step S1904 is searched for the print job name specified by the second argument ( Step S1906). If there is no file specified as the argument as a result of the search, an error response code is returned (steps S1907, 1915). The file of the list obtained in step S1902, step S1904, or step S1906 is opened (step S190
8). Send the file contents when opened (S
1911). When the transmission is normally completed, a normal completion response code is returned (step S1914). If the transmission fails, an error response code is returned (step S1913).

Reception Processing by XNS Server Section FIG. 20 is a diagram showing an outline of processing of the XNX server function of the XNX server section 16. The XNX server unit 16 checks whether there is a request from the remote host (step S2001). If there is a request, determine what the request is, perform each process, and return a response to the remote host (step S2
003 to S2007), if not present, wait until there is a processing request (step S2002). There are the following four requirements. Details will be described later. Print Processing A print request from a remote host is accepted (step S2004). Print processing result inquiry Returns the processing result of the print request (step S2).
005). Printer status inquiry Returns the status of the gateway (whether spooling possible, processing in progress, etc.) (step S2006). Printer attribute inquiry Returns the attribute information (printable paper size, double-sided printing, etc.) accepted by the gateway (step S2).
007).

Print Processing FIG. 21 shows XNS in response to a print processing request from the host.
It is a figure which shows the flow of a process of the server part 16. In the XNS server unit 16, first, the host that issued the print processing requests
It is checked whether the host is a registered host (step S2101), and if the host is not registered, an error is returned (step S2102). Next, it is checked whether the user is a registered user (step S2103), and if not registered, an error is returned (step S210).
4). Next, it is checked whether the process is in the operating state (step S2105), and if it is not in the operating state, an error is returned (step S2106). Next, it is checked whether it is in the reception acceptable state (step S2107), and if it is not in the reception acceptable state, an error is returned (step S210).
8). Furthermore, it is checked whether the spool capacity is sufficient (step S2109), and if the spool capacity is insufficient, an error is returned (step S2110). Also,
It is checked whether the queue area is sufficient (step S2111), and if the queue area is insufficient, an error is returned (step S2112). Next, the length of the received file name is checked (step S2113), and if 26 characters or more exceeding the allowable value are returned, an error is returned (step S21).
14). When the above checks are passed, the file starts to be received (step S2115). If writing fails during file reception, an error is returned (steps S2116 and S2117). If the reception is successful, a queuing request is made to another processing unit (not shown) in the gateway 10 (step S2118). The result of the queuing is checked (step S2119), if it fails, an error is returned (step S2120), and if it succeeds, the job identification ID is returned (step S2121).

Print Processing Result Inquiry FIG. 22 is a diagram showing a processing flow of the XNS server unit 16 in response to a print processing result inquiry from the host. XN
The S server unit 16 first checks whether the host name of the requested host is registered (step S2).
201), if the host name is not registered, an error is returned and the process ends (step S2202). If the host name is not registered, the processing result of the corresponding job is checked from the job management information (step S220).
3) returns a response (step S2204).

Printer Status Inquiry FIG. 23 shows an XN for the printer status inquiry from the host.
It is a figure which shows the flow of a process of the S server part 16. Check if the host name is registered (step S2
301), if the host name is not registered, an error is returned and the process ends (step S2302). If the host name is registered, the disk usage rate is checked (step S2303), and if the spool capacity is exceeded, the spool status is set to disabled (step S2304). Otherwise, set spool status = enabled (step S
2305). Next, it is checked whether or not all the connected printers are in the stopped state (step S2306). If all the connected printers are in the stopped state, the formatter and printer = disable are set (step S2307). If not, the formatter and printer are set to "OK" (step S2).
308). Acceptable paper size = A4, A3, B
4 and B5 are set (step S2309). Finally, the items set above are returned as a response (step S2310).

Printer Attribute Inquiry FIG. 24 shows an X in response to a printer attribute inquiry from the host.
It is a figure which shows the processing flow of the NS server part 16. Check if the host is registered (step S2)
401). If the host name is not registered, an error is returned and the process ends (step S2402). If the host name is registered, "Receive double-sided printing. Accept stapler. Acceptable paper size is A4, A
3, B4 and B5. Printer attribute information is set in the response (step S2403). Then, the set response is returned (step S2404).

XNS Printing Client Unit
25. Transmission process by 17 FIG. 25 shows the XNS Printing client unit 1
It is a process flow diagram of No. 7. 1) After starting, it is checked whether or not there is a processing request (step S2501). 2-1) If there is no request, inquire about the current state of the printer such as whether the printer is currently stopped, is in a busy state, or is available (step S2510). As a result, if the printer is available, how is the processing of the print job for which the print request has already been made progressing, that is, whether the print job is being performed, the print is finished, or the waiting state. , Inquires about whether or not it has been canceled (steps S2511, S2513). 2-2) If there is a print request, or if there is a print request as a result of the check in step S2501, inquire about the printer status (step S2).
503). As a result of the inquiry, if the printer is available, the result is inquired (step S2506). If there is a transmission file, a print request is made (steps S2507 and S2).
508). 2-3) If there is a stop request, as a result of the check in step S2501, if there is a stop request, stop processing is performed and the process ends (step S2502).

In the first embodiment described in detail above, in addition to the FTP client function and the FTP server function as the receiving unit, the XNS server function capable of accepting the protocol XNS supported by the printer is provided.
The gateway can be used even from the host that made a print request directly to the printer,
Host connectivity is improved. In addition, by not sending a print request by the XNS protocol directly to the printer but via a gateway, the spool area of the printer is limited, the connection that can be connected to the printer at the same time is restricted, and the status of the printer such as unacceptable when the printer is down Print request acceptance is no longer affected by. Further, in the present embodiment, the number of types of connections is increasing. Therefore, if the conventional extension is used to manage the connections, the management becomes complicated and the processing becomes inefficient. Since the management of is done by the connection identifier and the connection type, the connection can be efficiently managed by the protocol. Further, the connection identifier can be used not only for managing the connection but also for writing / reference of logging information, writing / reference of history / account, reference / cancellation of print request, and the like. For example, by writing the logging information in a file corresponding to the connection ID, it is possible to easily search for each connection. At this time, print requests from undefined hosts or users may be stored based on the special connection ID.

(Second Embodiment) When exchanging requests / data between a gateway and a printer in the conventional technique, first, a connection (communication path) is opened in a lower layer (network layer) of the OSI 7 layer, and The upper layer data was exchanged using the connection, and the connection was always released when the data exchange was completed. With this method, if data is frequently exchanged,
Every time I opened / released the connection, I couldn't exchange data efficiently. This embodiment solves this problem. As shown in FIG. 26, in this embodiment, a plurality of host computers 261 ₁ that have different protocols such as protocol FTP or protocol XNS (simply referred to as “host”) are provided.
.. 261 _n , a plurality of printers 262 _{1 to} 262 _m having the protocol XNS, and a gateway 260 having both the protocol FTP and the protocol XNS are present on the same logical network 263. As with the first embodiment, the gateway 260 has the management unit 267 that manages the connection described in FIG. 4, and also manages using the timer 268. The file transfer between the host and the gateway is performed through the communication protocols FTP and TCP / IP supported by the host, and the reception processing is performed by the FTP server unit 264. The file transfer between the gateway and the printer is transferred by the communication protocol XNS Printing supported by the printer. XNS to process
This is performed by the Printing client unit 265 and its lower layers. The gateway 260 has a spool 266 that temporarily stores files received from the host.
There is.

FIG. 27 shows a flow of processing procedure between the gateway and the printer. The XNS Printing client unit 265 checks whether or not there is a process to be transmitted to the print system (step S271), and at some time checks whether or not a connection with the printer is established (step S272). For example, the transmission process is executed (step S273), and if not established, the connection establishment process is executed (step S274), and then the transmission process is executed (step S274).
275). When the processing is completed, the timer 268 is set (step S276) and the timer is started. It is checked whether it has timed out (step S27).
7) If the time has not expired, the connection is not released. If the time has expired, the connection is released (step S278). It should be noted that, if there is no processing request for a certain period of time after setting the timer, the timeout occurs, and if there is a processing request within the certain period of time after setting the timer, the timeout does not occur.

FIG. 28 shows an example of the processing sequence of this embodiment, and FIG. 29 shows an example of the processing sequence of the conventional example for comparison. A connection is opened between the gateway and the printer, and after the processing such as data exchange is performed, the connection is released. In the conventional sequence shown in FIG. 29, the connection is always released when the connection is opened and one process such as data exchange is performed. That is, the connection was always opened and released for each process. Therefore, when data is frequently exchanged, it is not possible to perform efficient data exchange because the connection is always opened and released each time. In this embodiment, as shown in FIG. 28, a timer is started after exchanging data, the connection is released when a certain time set in the timer elapses, and a timer is issued when the next processing request is made within the certain time. To perform the requested processing. Therefore, when data is frequently exchanged, the connection once established can be used many times and data can be efficiently exchanged.

[0040]

According to the present invention (Claim 1), since the connection is managed by the connection identifier and the connection type, the connection can be managed efficiently by the protocol.

Further, according to the present invention (claim 2), after the connection is established, the release of the connection is delayed when the next processing request is made within a predetermined time, so that frequent data exchange is possible. When performed, the connection once established can be used many times, and data can be efficiently exchanged.

Further, according to the present invention (Claim 3), the means (XNS server function) for accepting the print request by the communication protocol supported by the printer is provided.
The gateway can be used even from the host that made a print request directly to the printer,
Connectivity is improved. Also, by accepting print requests via the gateway in this way,
The print request acceptance is no longer restricted to the printer side such as the spool area limitation of the printer, the connection limitation that can be connected to the printer at the same time, and the inability to accept when the printer is down.

[Brief description of drawings]

FIG. 1 is a diagram showing an outline of a configuration of a first embodiment of the present invention.

FIG. 2 is a diagram for explaining a data flow from a host to a printer.

FIG. 3 is a diagram for explaining a data flow from a host to a printer.

FIG. 4 is a diagram showing a configuration related to connection management of a gateway.

FIG. 5: Spool connection information file (FTP
Diagram showing the description format and description example of the connection host description file in the client function)

FIG. 6 is a diagram showing a description format and a description example of an FTP connection information file (connection host description file in the FTP server function).

FIG. 7 is a diagram showing a description format and description example of an XNS connection information file (connection host description file in the XNS server function).

FIG. 8 is a printer connection information file (XNS
A diagram showing a description format and a description example of a connection host description file in the printing server function)

FIG. 9 is a diagram showing a description example of a printer assignment information name file.

FIG. 10 is a diagram showing a storage format of FTP connection information in a memory.

FIG. 11: FTP server function of gateway, XNS
Flow diagram showing the outline of the reception process for the connection request from the host to the server function

FIG. 12 is a process flow chart of the FTP client function.

FIG. 13: STO showing transmission in FTP command
Diagram showing a flow of a series of processing using R (1)

FIG. 14 is a diagram (2) showing a flow of a series of processes using STOR which is a command indicating transmission in the FTP command.

FIG. 15 is a diagram (3) showing a flow of a series of processes using STOR which is a command representing transmission in the FTP command.

FIG. 16 is a diagram showing a flow of a series of processes using the FTP command LIST (1).

FIG. 17 is a diagram showing a flow of a series of processing using the FTP command LIST (2).

FIG. 18 is a diagram showing a flow of a series of processing using FTP command NLST (1).

FIG. 19 is a diagram showing a flow of a series of processing using the FTP command NLST (2).

FIG. 20 is a diagram showing a processing flow of an XNS server function.

FIG. 21 is a diagram showing a flow of processing for a print processing request.

FIG. 22 is a diagram showing a flow of processing for a print processing result inquiry.

FIG. 23 is a diagram showing a flow of processing for a printer status inquiry.

FIG. 24 is a diagram showing the flow of processing for a printer attribute inquiry.

FIG. 25 is a diagram showing a flow of processing of an XNS Printing client function.

FIG. 26 is a diagram showing a schematic configuration of a second embodiment of the present invention.

FIG. 27 is a diagram showing a processing flow of opening / closing a connection.

FIG. 28 is a diagram showing an example of a processing sequence of the second embodiment.

FIG. 29 is a diagram showing an example of a conventional processing sequence.

[Explanation of symbols]

11 _{1 to} 11 _n ... host, 12 _{1 to} 12 _n ... printer, 13
... network, 14 ... FTP client section, 15 ...
FTP server section, 16 ... XNS server section, 17 ... XNS
Printing client section, 18 ... Management section, 19
…spool.

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Takeshi Kogane 3-2-1 Sakado, Takatsu-ku, Kawasaki-shi, Kanagawa KSP / R & D Business Park Building Fuji Xerox Co., Ltd. (72) Toru Nakatani Takatsu, Kawasaki-shi, Kanagawa 3-2-1, Sakado, Kusu KSP / R & D Business Park Building Fuji Fuji Xerox Co., Ltd.

Claims (3)

[Claims] 1. A gateway system in which a plurality of devices having different communication protocols are connected to a common transmission medium by a single interface and protocol-convertible data transfer is performed between the plurality of devices. A gateway system comprising first management means for managing each connection to a device with a connection identifier and a connection type. 2. The gateway system according to claim 1, further comprising second management means for delaying release of the connection when a next processing request is made within a predetermined time after the connection is established. 3. The plurality of devices having different communication protocols include a printer supporting a certain communication protocol and a data processing device capable of making a print request by the communication protocol supported by the printer, 2. The gateway system further comprises means for accepting a print request according to a communication protocol supported by the printer and transmitting the accepted request to the printer according to a communication protocol supported by the printer. Gateway system.