JP2007272490A - Transmission source apparatus for transmitting file by ftp - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To allow a transmission source apparatus which has transmitted a file by an FTP (File Transfer Protocol), to recognize whether the file having had reached a transmission destination apparatus has a deficit or not. <P>SOLUTION: A transmission source apparatus (10) includes; a transmission means (35) for transmitting a file in accordance with the FTP; an inquiry means (34) for inquiring of a transmission destination apparatus (50) about file information of the file having had reached the transmission destination apparatus; and a judgment means (33) which causes the transmission means to transmit the file and then causes the inquiry means to inquire about file information of the file and judges whether the file having had reached the transmission destination apparatus has a deficit or not on the basis of a file size in file information returned from the transmission destination apparatus in response to the inquiry and a file size of the transmitted file. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a transmission source device that transmits a file by FTP (File Transfer Protocol).

  Conventionally, a function of transmitting a file from a transmission source device (transmission side server) and performing error checking of the received file (for example, checking whether or not a data file is missing). There is known a file transfer system including a transmission destination device (reception side server) having the information (for example, see Patent Document 1).

  In this file transfer system, the transmission source device transmits a data file storing predetermined data, a byte file indicating the number of bytes of the data file, and the like to the transmission destination device, and the transmission destination device receives these files. The received file is checked for errors by comparing the number of bytes of the received data file with the number of bytes of the data file indicated by the byte file.

JP 2005-276129 A

  Only a part of the transmitted file reaches the destination device due to an unstable communication network or the like, that is, the file that reaches the destination device (specifically, for example, a specified directory May be missing. According to the technique disclosed in Patent Document 1 described above, the transmission destination device can determine whether or not the received data file is missing from the received data file and byte file.

  There may be a need for the transmission source device to recognize it. However, particularly in file transmission according to FTP (File Transfer Protocol), due to FTP restrictions, the transmission source device cannot recognize whether or not the file that has reached the transmission destination device is defective. Even so, even if a file arrives at the transmission destination device, the transmission source device cannot recognize it. Specifically, when a file is transmitted by FTP, an application program can execute a file transmission program that transmits a file by FTP in the transmission source apparatus, thereby causing a desired file to be transmitted by FTP. In the response returned from the file transmission program to the application program, there is a report that the file has been transmitted, but there is no report whether or not the file has arrived at the transmission destination device.

  Accordingly, an object of the present invention is to enable a transmission source apparatus that has transmitted a file by FTP to recognize whether or not a file that has arrived at the transmission destination apparatus is defective.

  Other objects of the present invention will become clear from the following description.

  The transmission source device according to the present invention includes transmission means for transmitting a file according to FTP, inquiry means for inquiring the file information of the file that has reached the transmission destination device of the file, and determination means. The determination unit causes the transmission unit to transmit the file, and then causes the inquiry unit to make an inquiry about the file information of the file. The file size in the file information returned from the transmission destination apparatus in response to the inquiry And whether or not there is a defect in the file that has arrived at the transmission destination device, based on the file size of the transmitted file.

  ADVANTAGE OF THE INVENTION According to this invention, the transmission source apparatus which transmitted the file by FTP can recognize now whether the file which arrived at the transmission destination apparatus has a defect | deletion.

  Inquiry of the file information to the inquiry unit can be automatically performed in response to the transmission of the file by the transmission unit. Alternatively, when the transmission unit transmits a file, if the determination unit reports the file transmission, it is possible to cause the inquiry unit to inquire the file information. It can be done automatically when triggered. As a result, it is possible to quickly recognize whether or not a file arrives at the transmission destination device.

  The FTP transfer mode includes a binary mode and an ASCII mode. When the present invention is applied to file transmission in the binary mode, for example, the file size of the transmitted file and the file in the returned file information are included. It is possible to determine whether or not there is a defect in the file that has arrived at the transmission destination device by comparing the sizes and whether or not they match. In binary mode, the file is sent without changing special codes such as line feed code, so if the file is delivered to the destination device without loss, the file size will not change between the source device and the destination device. It is.

  However, in the file transmission in the ASCII mode, simply applying this method cannot accurately determine whether or not the file that has arrived at the transmission destination device is missing. In ASCII mode, unlike the binary mode, a special code such as a line feed code is changed and sent. Therefore, even if the file reaches the destination device without loss, it reaches the destination device and the file size of the file to be sent. This is because the file size of each file is different. This usually occurs as long as the OS type of the transmission source device and the transmission destination device are not the same. Specifically, in the ASCII mode, when a file is transmitted by the transmission unit, the code size of the special code is larger than the code size of the transmission source device according to the OS (Operating System) type of the transmission destination device. The special code itself can be removed or added. For this reason, there is a difference between the file size of the transmitted file that can be recognized by the determination means and the file size of the file that has arrived at the transmission destination device.

  Accordingly, in the first embodiment of the present invention, the first code size storing means for counting the number of special codes included in the transmitted file and the first file size change rule for each OS type are stored. Storage means. When the file is transmitted in the ASCII mode, the determination means includes a file size of the file, a special code count value, a file size in the file information returned from the transmission destination device, and the transmission destination device. Based on the installed OS type and the first file size change rule corresponding to the OS type, it is determined whether or not there is a defect in the file that has reached the destination apparatus.

  Thereby, even when the file is transmitted in the ASCII mode, it is possible to accurately determine whether or not the file that has reached the transmission destination device has a defect.

  In the second embodiment, a second storage unit that stores a second file size change rule for each OS type and an OS specifying unit that specifies the OS type of the transmission destination device are further provided. The OS specifying means transmits the file in the ASCII mode according to FTP by the transmitting means, inquires the file information of the file to the transmission destination apparatus by the inquiry means, and the file size in the file information returned by the inquiry Based on each second file size change rule, the corresponding OS type is specified from the second storage means. The OS type based on the determination unit is the OS type specified by the OS specifying unit.

  According to this embodiment, even if the user does not know the type of OS installed in the transmission destination device, it can be specified by the transmission source device. The second file size change rule may be the first file size change rule. Therefore, the second storage unit may be the first storage unit. In other words, the OS type may be specified based on the same file size change rule as the file size change rule based on the determination by the determination means. Thereby, it is possible to save the consumption amount of the storage resource in the transmission source device.

  In the third embodiment, in the second embodiment, when the file is transmitted in the binary mode, and even if the file is transmitted in the ASCII mode, the OS type of the transmission destination device has been specified. In some cases, the OS specifying unit is not executed, and the OS specifying unit is executed when the file is transmitted in the ASCII mode and the OS type of the destination device is not specified.

  According to this embodiment, it is possible to prevent the OS specifying unit from being executed unnecessarily, so that it is not delayed to recognize whether or not the file that has reached the transmission destination device is missing. Can be.

  In the fourth embodiment, in the first or second embodiment, the file size change rule may be constituted by a size increase / decrease value corresponding to the type of the special code. The special code is, for example, at least a line feed code of a line feed code and an end code.

  In the fifth embodiment, in the second embodiment, the file transmitted for specifying the OS type is an inspection file prepared for specifying the OS type, and the inspection file is: At least the special code may be included.

  According to this embodiment, an inspection file including a special code that causes a difference in file size due to a difference in OS type between a transmission source device and a transmission destination device is prepared. However, it can be expected that the OS type of the transmission destination apparatus is specified reliably.

  In the sixth embodiment, in the second embodiment, the OS specifying unit repeats the file transmission and the file size inquiry M times (an integer of M ≧ 2), and the same file size is N times (N If it is obtained, the corresponding OS type is specified from the second storage means based on the same file size.

  Due to the instability of the communication network, the transmitted file does not necessarily reach the destination device without loss, and even if it arrives without loss, correct file information is not always returned. For this reason, there is a possibility that an incorrect OS type may be specified by specifying the OS type by one file transmission and one inquiry. According to the seventh embodiment, when file transmission or inquiry is repeated M times and the same file size is obtained N times, the OS type is specified based on the file size. For this reason, the specific accuracy of the OS type can be improved.

  In the seventh embodiment, a session connection / disconnection means for connecting or disconnecting a session with the transmission destination device is further provided. After transmitting the file, the transmission source device disconnects the session at the time of transmission of the file by the session connection / disconnection means, and then newly connects the session with the transmission destination device, and the file of the file Ask for information.

  If the file information is obtained in the same session used when sending the file, and if the session is a session in which a loss has occurred in the file that has reached the destination device, the file in the faulty session Since the information has been acquired, there may be an error in the acquired file information. Even if the file size in the wrong file information is used, it cannot be correctly determined whether or not the file is missing. In the eighth embodiment, the session used for file transmission and the session used for file information inquiry are independent. Thereby, it can be expected to reduce the possibility that incorrect file information is acquired.

  Each unit described above can also be realized by hardware (for example, a circuit), a computer program, or a combination thereof (for example, one or a plurality of CPUs that read and execute a computer program). Each computer program can be read from a storage resource (for example, memory) provided in the computer machine. The storage resource can be installed via a recording medium such as a CD-ROM or DVD (Digital Versatile Disk), or can be downloaded via a communication network such as the Internet or a LAN.

  Hereinafter, a file transfer system according to an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 shows the configuration of a file transfer system according to an embodiment of the present invention.

  The transfer source machine 10 and the transfer destination machine 50 are connected to the communication network 100 so that they can communicate with each other. Both the transfer source machine 10 and the transfer destination machine 50 are a kind of computer.

  First, the transfer source machine 10 will be specifically described.

  The transfer source machine 10 includes a CPU 11, an I / O interface unit 12, and a storage resource 20. The CPU 11 can read a computer program from the storage resource 20 and execute it. The I / O interface unit 12 functions as an interface of the CPU 11 with respect to the communication network 100.

  The storage resource 20 can be configured by a memory or a hard disk drive provided in the transfer source machine 10. The storage resource 20 includes an OS identification table 40, an OS 42 such as Windows (registered trademark) or UNIX (registered trademark), a file transmission unit 35, a file information inquiry unit 34, a session connection / disconnection unit 22, and a defect presence / absence check processing unit 30. I remember it.

  The OS specification table 40 records file size change rules for each OS type. The file size change rule is, for example, information indicating a file size change method or a change result of a file transmitted in the ASCII mode, and the OS type can be specified at least from the returned file size. If so, various information can be adopted. For example, it may be an increase / decrease value of the file size in one special code unit whose size increases / decreases depending on the OS type of the transfer destination machine 50, or the changed file size corresponding to the file size of the transmitted file. It may be itself. In this embodiment, the file size change rule is information composed of a size increase / decrease value for each line feed code (that is, for each line) and a size increase / decrease value related to the presence / absence of an end code, as illustrated in FIG. 2A. is there. The size increase / decrease value related to the presence / absence of the end code is, for example, “0” when the end code is not necessary, and “1” when the end code is necessary. The unit of various size increase / decrease values can be bytes. Each file size change rule recorded in the OS specifying table 40 is a rule for other types of OSs based on the OS 42 of the transfer source machine 10.

  The file transmission unit 35 transmits a file according to FTP. Specifically, the file transmission unit 35 transfers the file in either the ASCII mode or the binary mode. The ASCII mode is a transfer mode for guaranteeing the appearance of a file in the transfer destination machine 50, specifically, a transfer mode in which a special code such as a line feed code is changed according to the OS type of the transfer destination machine 50. It is. For this reason, the ASCII mode is often used for transmitting text files. On the other hand, the binary mode is a transfer mode in which a file to be transmitted is transmitted as it is to the transfer destination machine 50, specifically, a transfer mode in which the code size is transmitted as it is regardless of the type of code. Unlike the transfer destination machine 50, it does not guarantee the appearance of the file.

  The file information inquiry unit 34 inquires of the FTP service 70 of the transfer destination machine 50 about the file information of the file transmitted from the file transmission unit 35 and arrived at the transfer destination machine 50 and accepts a reply from the FTP service 70. The file information is information including various information elements related to the file. Examples of the information element include, in addition to the file size, information on the file name, file update date / time (time stamp), access right, and the like. .

  The session connection / disconnection unit 22 connects a session with the transfer destination machine 50 or disconnects the session.

  The file transmission unit 35, the file information inquiry unit 34, and the session connection / disconnection unit 22 described above are computer programs that execute predetermined commands supported by FTP, and may be existing programs, for example.

  On the other hand, the defect presence / absence check processing unit 30 is, for example, a kind of application program and is one of the features of the present embodiment. The defect presence / absence check processing unit 30 controls the file transmission unit 35, the file information inquiry unit 34, and the session connection / disconnection unit 22 so that the file is transmitted in either the binary mode or the ASCII mode. However, it is possible to accurately determine whether or not the file has arrived at the transfer destination machine 50 without any loss. For example, the defect presence / absence check processing unit 30 extracts the file name and file size from the file information of the transmission target file, temporarily stores the extracted file name and file size in the storage resource 20, and then transmits the transmission target file. The file transmission unit 35 can execute the file transmission. Further, the defect presence / absence check processing unit 30 causes the file information inquiry unit 35 to execute the file information inquiry of the transmitted file, and thereby extracts the file name and file size from the file information returned from the transfer destination machine 50. Then, the extracted file name and file size can be temporarily stored in the storage resource 20. Further, the missing / missing check processing unit 30 causes the session connection / disconnection unit 22 to connect a session with the transfer destination machine 50 at an arbitrary timing, or causes the session connection / disconnection unit 22 to disconnect the session. You can also.

  The defect presence / absence check processing unit 30 includes an OS identification unit 31, a predicted file size calculation unit 22, and a defect presence / absence determination unit 33.

  The OS specifying unit 31 specifies the type of the OS 72 of the transfer destination machine 50. Specifically, the OS specifying unit 31 transmits a later-described inspection file to the transfer destination machine 50 by the file transmission unit 35, and inquires the FTP service 70 of the file size of the inspection file by the file information inquiry unit 34, Based on the file size of the transmitted file, the file size in the returned file information, and the OS specification table 40, the OS type of the transfer destination machine 50 is specified.

  The predicted file size calculation unit 32 calculates a predicted file size (hereinafter, predicted file size) when a file transmitted in the ASCII mode reaches the transfer destination machine 50 without any loss. Specifically, the predicted file size calculation unit 32 specifies a file change rule corresponding to the OS type specified by the OS specification unit 31 from the OS specification table 40, and specifies the specified file size change rule and the transmission target. The predicted file size is calculated from the number of line feed codes (that is, the number of lines) in the file and the file size of the transmission target file.

  The missing presence determination unit 33 compares the file size related to the transmitted file (specifically, the file size of the file or the predicted file size described above) with the file size returned from the transfer destination machine 50. It is determined whether or not the file that has arrived at the transfer destination machine 50 is missing.

  Next, the transfer destination machine 50 will be described.

  Similarly to the transfer source machine 10, the transfer destination machine 50 also includes a CPU 51, an I / O interface unit 52, and a storage resource 60. The storage resource 60 includes an OS 72, an FTP service 70, and a file storage unit 80. The file that reaches the FTP service 70 is stored in the file storage unit 80 by the FTP service 70.

  The above is the description of the configuration of the file transfer system according to the present embodiment. In the file transfer system according to the present embodiment, the flow of processing to be executed differs depending on the characteristics of the binary mode and the ASCII mode. Specifically, as shown in FIG. 2B, when the transfer mode to be executed is the binary mode (NO in S100), the process of FIG. 3 is executed and in the ASCII mode (YES in S100). 4) and FIG. 5 are executed. Hereinafter, a flow of processing performed when a file is transmitted in each transfer mode will be described. At that time, FIG. 3 shows the connection and disconnection of the session in detail, and FIG. 4 and FIG. 5 show a process for temporarily storing the file name and file size in the file information instead of showing it in detail. Show in detail.

  FIG. 3 shows the flow of processing performed when a file is transmitted in binary mode.

  The defect presence / absence check processing unit 30 acquires file information of a transmission target file (hereinafter, file F) in the storage resource 20 (step S1).

  Next, the defect presence / absence check processing unit 30 acquires a file name (may be another type of file ID) and a file size S1 from the acquired file information, and temporarily stores them in the storage resource 20 ( S2). Specifically, for example, the defect presence / absence check processing unit 30 instructs the OS 42 to temporarily store such information. Accordingly, a temporary file is prepared by the OS 42, and the file name and the file size S1 of the file F are stored in the temporary file.

  Next, the defect presence / absence check processing unit 30 issues a session connection request to the session connection / disconnection unit 22 (S3). Thereby, the session connection / disconnection unit 22 connects the session with the FTP service 70 of the transfer destination machine 50 (S4).

  Thereafter, the defect presence / absence check processing unit 30 requests the file transmission unit 35 to transmit the file F in the binary mode (S5). Thereby, the file transmission unit 35 transmits the file F to the storage destination directory in the binary mode (S6). The file F is received by the FTP service 70 and stored in a storage destination directory (specifically, for example, a directory designated by the user of the transfer source machine 10 or a predetermined directory) in the file storage unit 80 (S7). ).

  After the transmission of the file F, the missing presence check processing unit 30 issues a session disconnection request to the session connection / disconnection unit 22 (S7). As a result, the session connected / disconnected unit 22 disconnects the session connected in S4 (S8).

  Thereafter (for example, immediately after S7), the missing presence check processing unit 30 issues a session connection request to the session connection / disconnection unit 22 (S9). Thereby, a new session with the FTP service 70 of the transfer destination machine 50 is connected by the session connection / disconnection unit 22 (S10).

  Next, the defect presence / absence check processing unit 30 requests the file information inquiry unit 34 to acquire file information by designating the file name temporarily stored in S2 (S11). As a result, the file information inquiry unit 34 inquires of the FTP service 70 about the file information by designating the storage destination directory name and the file name (S12). As a result, the FTP service 70 acquires the file information of the file F having the file name existing in the storage destination directory of the storage destination directory name, and the acquired file information is returned from the FTP service 70. (S13).

  If the file information is returned, the defect presence / absence check processing unit 30 issues a session disconnection request to the session connection / disconnection unit 22 (S14). As a result, the new session connected in S10 is disconnected by the session connection / disconnection unit 22 (S15).

  The defect presence / absence check processing unit 30 acquires the file size S2 from the returned file information, and temporarily stores the acquired file size S2 in the storage resource 20 (S16).

  Then, the defect presence / absence check processing unit 30 compares the file size S1 temporarily stored in S2 with the file size S2 temporarily stored in S16 (S17). As a result, if a match is obtained, it means that the file F has arrived at the FTP service 70 without any loss. If a match is not obtained, the file F reaches the FTP service 70. It means that a defect may have occurred. For this reason, if there is no match, the defect presence / absence check processing unit 30 may automatically perform predetermined error processing, for example, resend of the file F without receiving an instruction from the user, You may report to

  The above is the description of the processing flow performed in the binary mode. Next, the flow of processing performed in the ASCII mode will be described.

  In the file transmission in the ASCII mode, as described above, the special code such as the line feed code is changed, but the change differs depending on the type of the OS 72 of the transfer destination machine 50. Therefore, if the type of the OS 72 of the transfer destination machine 50 is not known in advance, it cannot be accurately determined whether or not the file has arrived at the transfer destination machine 50 without any loss. This is because the file size in the file information returned by the inquiry is different from the file size of the transmission target file that can be recognized by the missing presence check processing unit 30.

  Therefore, in this embodiment, the OS pre-identification process is performed using a predetermined inspection file before transmitting the target file (the file to be actually transmitted) as necessary, and then the target file is transmitted. A defect presence / absence check process is performed to determine whether the file has arrived at the transfer destination machine 50 without any defect. Hereinafter, each processing will be described.

  FIG. 4 shows the flow of the OS pre-identification process performed when a file is transmitted in the ASCII mode.

  The inspection file C is prepared in the storage resource 20 in advance. This inspection file C includes a special code whose size increases or decreases depending on the type of OS, specifically, at least a line feed code.

  The defect presence / absence check processing unit 30 determines whether or not the OS type in the transfer destination machine 50 has been specified (S50). This determination is made, for example, by referring to a table indicating the correspondence between the ID (for example, IP address or WWN (World Wide Name)) of each computer and the OS type, using the ID of the transfer destination machine 50 as a search key. This can be done. Alternatively, it can be performed depending on whether or not the OS type is input from the user. If it is determined that the defect has been identified (YES in S50), the process after S71 in FIG. 5 is executed. If it is determined that the defect has not been identified, the following processes after S51 are performed. Execute.

  If NO in S50, the defect presence / absence check processing unit 30 acquires the file information of the inspection file C, acquires the file name and file size X1 from the file information, and the number of lines in the inspection file C (line feed) The number of codes) is counted, and the OS 42 is instructed to temporarily store the acquired file name and file size X1 and the counted number of lines (S51). Thereby, the OS 42 prepares the temporary file T1, and the file name, the file size X1 and the number of lines of the inspection file C are stored in the temporary file T1 (S52).

  Next, after connecting the session with the FTP service 70, the defect presence / absence check processing unit 30 requests the file transmission unit 35 to transmit the inspection file C to the FTP service 70 in the ASCII mode (S53). As a result, the file transmission unit 35 transmits the inspection file C to the storage destination directory in the ASCII mode (S54). The inspection file C is received by the FTP service 70 and stored in a storage destination directory in the file storage unit 80 (S55).

  Next, the defect presence / absence check processing unit 30 disconnects the session with the FTP service 70 and connects a new session, and then the file name temporarily stored in S51 (the file name in the temporary file T1). ) Is specified and the file information inquiry unit 34 is requested to acquire file information (S56). As a result, the file information inquiry unit 34 inquires the FTP service 70 about the file information by specifying the storage destination directory name and the file name (S57). As a result, the FTP service 70 acquires the file information of the inspection file C having the file name that exists in the storage destination directory of the storage destination directory name, and the acquired file information is obtained from the FTP service 70. A response is made (S58).

  When the file information is returned, the defect presence / absence check processing unit 30 disconnects the new session, thereafter acquires the file size X2 from the returned file information, and temporarily stores the acquired file size X2. This is instructed to the OS 42 (S59). Thereby, the OS 42 prepares the temporary file T2, and the file size X2 is stored in the temporary file T2 (S59).

  The defect presence / absence check processing unit 30 calculates the difference between the file size X1 in the temporary file T1 and the file size X2 in the temporary file T2 (S61).

  The processes of S51 to S61 are repeated until the same difference is obtained N (N is an integer of 2 or more) (NO in S62). This is to improve the accuracy of the OS type specified in S63 described later. In other words, the transmitted inspection file C does not necessarily reach the transfer destination machine 50 without any loss due to the instability of the communication network 100, and correct file information is returned even if it arrives without any loss. Therefore, there is a possibility that the wrong OS type may be specified by specifying the OS type by one file transmission and one inquiry. As described above, by repeating the processing of S51 to S61 until the same difference is obtained N (N is an integer of 2 or more) times, the accuracy of the OS type specified in S63 can be improved.

  When the same difference is obtained N times (YES in S62), the missing presence check processing unit 30 determines the difference (X1-X2), the number of lines in the temporary file T1 (the number of lines in the inspection file C), Based on the OS specifying table 40, the type of the OS 72 of the transfer destination machine 50 is specified (S63). Specifically, for example, in the example of FIG. 2A, when the difference (X1−X2) is −38 and the number of rows is 19, −38 is divided by 19 and −2 is obtained. The type can be specified as “CC”. When a remainder is generated by the division, the OS type can be specified by referring to the size increase / decrease value corresponding to the end code.

  After the OS type is specified as described above, a defect presence / absence check process can be performed. Note that the specified OS type is stored in the storage resource 20 in association with the ID of the transfer destination machine 50, and when the target file is transmitted thereafter, the processing after S51 is not performed. A defect presence / absence check process can be performed. As a result, there is no need to unnecessarily perform the OS pre-specific processing, so it is possible to quickly recognize whether or not the file has arrived at the FTP service 70 without any loss.

  FIG. 5 shows a flow of the defect presence / absence check process performed when a file is transmitted in the ASCII mode.

  The defect presence / absence check processing unit 30 acquires file information of a target file (hereinafter, file K) in the storage resource 20 (S71).

  Next, the defect presence / absence check processing unit 30 counts the number of lines in the file K, the file number s1 in the file information acquired in S71, and a file size change rule corresponding to the specified OS type. Based on (the file size change rule that can be specified from the OS specification table 40), a predicted file size s1 ′ that is a file size when the file K reaches the FTP service 70 without loss is calculated (S72). Specifically, for example, when the file size s1 is 200, the number of rows is 10, and the OS type is CC (see FIG. 2A), the predicted file size s1 ′ is 200+ (10 × −2) +1. = 181.

  The defect presence / absence check processing unit 30 instructs the OS 42 to temporarily save the file name and the predicted file size s1 ′ of the file K (S73). Thereby, the OS 42 prepares the temporary file t1, and the file name and the predicted file size s1 ′ of the file K are stored in the temporary file t1 (S74).

  Next, the defect presence / absence check processing unit 30 requests the file transmission unit 35 to transmit the file K to the FTP service 70 in the ASCII mode after connecting the session with the FTP service 70 (S75). As a result, the file transmission unit 35 transmits the file K to the storage destination directory in the ASCII mode (S76). The file K is received by the FTP service 70 and stored in the storage destination directory in the file storage unit 80 (S77).

  Next, the defect presence / absence check processing unit 30 disconnects the session with the FTP service 70 and connects a new session, and then specifies the file name in the temporary file t1 to acquire file information. The file information inquiry unit 34 is requested (S78). As a result, the file information inquiry unit 34 inquires of the FTP service 70 about the file information by designating the storage destination directory name and the file name (S79). As a result, the FTP service 70 acquires the file information of the file K having the file name existing in the storage destination directory of the storage destination directory name, and the acquired file information is returned from the FTP service 70. (S80).

  When the file information is returned, the defect presence / absence check processing unit 30 disconnects the new session, thereafter acquires the file size s2 from the returned file information, and temporarily stores the acquired file size s2. This is instructed to the OS 42 (S81). As a result, the OS 42 prepares a temporary file t2, and the file size s2 is stored in the temporary file t2 (S82).

  Then, the defect presence / absence check processing unit 30 compares the predicted file size s1 ′ in the temporary file t1 with the file size s2 in the temporary file t2 (S83). As a result, if a match is obtained, it means that the file K has arrived at the FTP service 70 without any loss. If a match is not obtained, the file K has reached the FTP service 70 and is missing. Means that this may have occurred. For this reason, if there is no match, the defect presence / absence check processing unit 30 may automatically perform predetermined error processing, for example, resend of the file F without receiving an instruction from the user, You may report to

  As described above, according to the above-described embodiment, the transfer source machine 10 that transmits a file by FTP has a defect in the file that has reached the transfer destination machine 50 regardless of whether the transfer mode is the binary mode or the ASCII mode. Whether or not there is can be recognized.

  In particular, in file transmission in the ASCII mode, special codes such as a line feed code are changed. Therefore, the file size in the file information returned by the inquiry can be recognized by the missing presence check processing unit 30 of the file to be transmitted. Because it is different from the file size, the same method as the method for checking whether there is a defect in the binary mode cannot accurately determine whether the file has arrived without a defect, but in the present embodiment, this is solved as follows. ing. That is, as described in detail with reference to FIG. 5, based on the OS type of the transfer destination machine 50, the file change rule corresponding to the OS type, the file size s1 of the file K, and the number of lines of the file K, The size s1 ′ is calculated and temporarily stored, and it is possible to determine whether or not the file is missing depending on whether or not the predicted file size s1 ′ matches the file size s2 in the returned file information. it can.

  Further, according to the above-described embodiment, the session used for file transmission and the session used for file information inquiry are independent. Thereby, it can be expected to reduce the possibility that incorrect file information is acquired. In other words, if the file information is acquired in the same session as that used when sending the file, and if the session is a session in which the file arrived at the transfer destination machine 50 is missing, there is a problem. Since the file information is acquired in the session, there may be an error in the acquired file information. However, according to the present embodiment, it can be expected to reduce the possibility of such a situation. .

  The embodiment of the present invention has been described above, but this is an example for explaining the present invention, and the scope of the present invention is not limited to this embodiment. The present invention can be implemented in various other forms.

  For example, a directory name may be stored in the temporary file in addition to the file name. Also, as a method for temporarily storing the file size of the file to be transmitted and the file size in the returned file information, instead of preparing a temporary file and storing it, it is stored in a predetermined area of the memory. Various other methods, such as a method of making them, can be employed.

  In addition, for example, a session disconnection request can be automatically made when a file is transmitted to the file transmission unit 35. Alternatively, when the file transmission unit 35 transmits a file and reports that the file has been transmitted to the missing presence check processing unit 30, the session disconnection request has received the report. This can be done automatically at the opportunity.

  Further, for example, a session connection request can be automatically made when the session connection / disconnection unit 22 disconnects the session. Alternatively, if the session connection / disconnection unit 22 disconnects the session and reports the session disconnection to the missing / missing check processing unit 30, the session connection request indicates that the report has been received. It can be done automatically as an opportunity.

  Further, for example, a file information acquisition request can be automatically made when a session is connected to the session connection / disconnection unit 22. Alternatively, if the session connection / disconnection unit 22 connects the session and reports the session connection to the lack check processing unit 30, the file information acquisition request has received the report. This can be done automatically at the opportunity.

  Further, for example, apart from the OS management table 40, there is a dedicated table for specifying the OS type, specifically, for example, a table in which the file size after conversion of the inspection file C is associated with each OS type. It may be prepared. In this case, the file size for each OS type is compared with the file size in the returned file information, and the OS type corresponding to the file size for which a match is obtained is determined as the OS type of the transfer destination machine 50. be able to.

  For example, in the defect presence / absence check process of FIG. 5, the following method may be employed instead of the method of calculating the predicted file size s1 ′. That is, the presence / absence of a defect may be determined based on the difference between the file size s2 and the file size s1, the number of lines, and the file change rule corresponding to the OS type. Specifically, for example, similarly to the above-described example, when the file size s1 is 200, the file size s2 is 181, the number of lines is 10, and the OS type is CC (see FIG. 2), the increase by the end code Determining whether or not there is a loss by subtracting 1/181 from 181 and dividing (180-200) by the number of lines 10 is equal to the value -2 obtained by dividing the increase / decrease value of the OS type CC. May be done.

  For example, the session does not necessarily have to be disconnected after the file information is returned.

1 shows a configuration of a file transfer system according to an embodiment of the present invention. FIG. 2A shows a configuration example of the OS identification table. FIG. 2B shows a flow in which processing according to the transfer mode is selected. The flow of processing performed when a file is transmitted in binary mode is shown. The flow of OS pre-specific processing performed when a file is transmitted in the ASCII mode is shown. The flow of a defect presence / absence check process performed when a file is transmitted in the ASCII mode is shown.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 10 ... Transfer source machine, 11 ... CPU, 12 ... I / O interface part, 20 ... Storage resource, 22 ... Session connection / disconnection part, 30 ... Missing presence check processing part, 31 ... OS specification part, 32 ... Predictive file size Calculation unit 33... Missing presence / absence determination unit 34... File information inquiry unit 35... File transmission unit 40. OS identification table 42. OS 50 50 Transfer destination machine 51 CPU 45 I / O interface unit , 60 ... storage resource, 70 ... FTP service, 72 ... OS, 80 ... file storage unit, 100 ... communication network

Claims (9)

A transmission means for transmitting a file according to FTP (File Transfer Protocol);
Inquiry means for inquiring of the destination device about file information of the file that has reached the destination device of the file;
The file is transmitted by the transmission unit, and thereafter the file information of the file is inquired by the inquiry unit. The file size in the file information returned from the transmission destination apparatus in response to the inquiry, and the transmission A transmission source device comprising: a determination unit configured to determine whether or not the file that has arrived at the transmission destination device has a defect based on a file size of the file that has been received. A special code counting means for counting the number of special codes contained in the file to be transmitted;
A first storage means for storing a first file size change rule for each OS (Operating System) type;
The special code is a code in which the code size at the transmission destination device can be increased or decreased compared to the code size at the transmission source device and / or the transmission destination in file transmission in ASCII mode. A code that can be removed or added in the device;
When the file is transmitted in the ASCII mode, the determination means includes a file size of the file, a count value of the special code, a file size in the file information returned from the transmission destination device, and the transmission destination device. Based on the installed OS type and the first file size change rule corresponding to the OS type, it is determined whether or not the file that has arrived at the transmission destination device is missing.
The transmission source device according to claim 1. A second storage means for storing a second file size change rule for each OS type;
An OS specifying means for specifying the OS type of the destination device;
The OS specifying unit transmits the file in the ASCII mode by the transmitting unit, inquires the file information of the file to the transmission destination device by the inquiry unit, and determines the file size and each of the file information in the file information returned by the inquiry. Based on the second file size change rule, the corresponding OS type is identified from the storage means,
The OS type based on the determining means is the OS type specified by the OS specifying means.
The transmission source device according to claim 2. If the file is transmitted in the binary mode, and the OS type of the transmission destination device is already identified even if the file is transmitted in the ASCII mode, the OS identifying unit is not executed and the file is Is transmitted in ASCII mode, and the OS identification unit is executed when the OS type of the destination device is unspecified.
The transmission source device according to claim 3. The first or second file size change rule is composed of a size increase / decrease value according to the type of the special code,
The transmission source device according to claim 2 or 3. The file transmitted for specifying the OS type is an inspection file prepared for specifying the OS type, and the inspection file includes at least the special code.
The transmission source device according to claim 3. When the OS specifying means repeats the file transmission and the file information inquiry M times (M ≧ 2 integer), and the same file size is obtained N times (N ≦ M and N ≧ 2 integer). In addition, based on the same file size, the corresponding OS type is identified from the second storage means.
The transmission source device according to claim 3. Session connection / disconnection means for connecting or disconnecting a session with the destination device is further provided, and after the file is transmitted, the session at the time of transmission of the file is disconnected by the session connection / disconnection means. Then, a new session is connected to the transmission destination device, and the file information of the file is inquired.
The transmission source device according to any one of claims 1 to 7. Sending a file to a destination device by a sending means for sending the file according to FTP;
A step of inquiring file information of the transmitted file to inquiry means for inquiring the file information to the transmission destination device after transmitting the file;
Based on the file size in the file information returned from the transmission destination device in response to the inquiry and the file size of the transmitted file, it is determined whether or not the file that has reached the transmission destination device is defective. A computer program for causing a computer to execute the determining step.

Images