HULFT Short Stories

Vol.6 Asynchronous and synchronous transfer

Hello.
My name is Okazaki and I am in charge of HULFT seminar.

Last week, it snowed for the first time in Tokyo.
It is said that snow has accumulated in Tokyo in November for the first time in the history of observation, and winter has arrived in earnest before December.
2016 will end in one month, and the end of the year will be hectic, but everyone, please take care of your physical condition.

In this HULFT story, I would like to introduce a little more depth on "HULFT transfer" as in the previous article.
In the previous short story, we introduced "Transfer Speed Priority Mode" and "Anomaly Detection Priority Mode" under the theme of "TCP and HULFT Forwarding".
The difference was whether to do "message receipt notification" asynchronously or synchronously.

Click here for the last HULFT short story

HULFT allows you to choose from a variety of functions and modes for file transfer, and there are many ways to send a single file.
This time, we will introduce the asynchronous and synchronous transfer of "file transfer".

Before we dive into the differences between asynchronous and synchronous transfers, let's briefly introduce how file transfer in HULFT works.
There are two main ways to transfer HULFT file transfer.
send "send request" that commands the file "Don't send it!" from the side, and "Send me the file" from the receive side. and "send request".

This time, we will use "send Request" as an example.
I would like to explain.

HULFT has a send request command called "utlsend".
When "utlsend" is issued, the HULFT send system is sent the command "Don't send the file!"
The send system that receives it transfers the file to the HULFT on the receive side.

The difference in how far the scope of this file transfer transaction is perceived is the difference between "asynchronous transfer" and "synchronous transfer".

Some people may find it difficult to imagine asynchronous transfer or synchronous transfer.
In general, asynchronous is defined as "performing the next process without the result of another process", and synchronous is defined as "performing the next process based on the result of another process".

send Let's take the example of the movement when you run the request command "utlsend".

If you want to sync with HULFT, run the command with the parameter "-sync" behind "utlsend".
At this time, you cannot operate the command during file transfer.
When the file transfer is complete, you can perform the following command operations:

Now that you have a clear idea of what "asynchronous" and "synchronous" mean, let us briefly explain how HULFT 's "asynchronous transfer" and "synchronous transfer" work.

With HULFT 's "asynchronous transfer," the result of the request is returned to the sender as soon as send request is issued, without waiting for the result of whether file transfer ended successfully or abnormally.
In this case, even if the request is issued successfully, it does not mean that file transfer has been completed successfully.
Therefore, the next process will be executed without worrying about the result of file transfer.

On the other hand, "synchronous transfer" waits for the results of file transfer before returning the results of the request.
In this case, the sender will know whether file transfer was successful or not.
Therefore, you can check the return value of the transfer result and execute processing according to whether the transfer was successful or unsuccessful.

When using HULFT for normal business operations, it is not just a matter of file transfer; in most cases, it is linked to other business processes.
I think there are cases where you want to check whether file transfer was successful or not and then use the return value to trigger other processing.
In such cases, you need to check the transfer results using synchronous transfer.
For example, if you need to ensure that data (files) between servers are kept in the same state, or if you want to perform a process to change or delete files on send side after file transfer, you will want to process the data using synchronous transfer.

On the other hand, if you want to continue working regardless of the results of file transfer, asynchronous transfer is fine.
One case where asynchronous transfer is necessary is when a single file needs to be sent to multiple locations simultaneously.
In this type of transfer, the next process cannot proceed until the transfer to all locations is complete, so if file transfer to one location does not go well, the entire process will be delayed.
If you are concerned about the overall time required for business or system processing, asynchronous transfer may be the best option.

The results of file transfer are managed by HULFT.
Furthermore, by controlling the timing of the next process in file transfer, HULFT can be used not only as a transfer tool, but also as a business collaboration tool.

This time, we introduced two transfer methods, "asynchronous transfer" and "synchronous transfer," as functions related to file transfer.

How was it?

The scope of file transfer transactions will vary depending on the customer's business, so we hope you will keep this function in mind when designing your operations.

In future HULFT anecdotes, I would like to introduce some key points to keep in mind when using HULFT.

Please look forward to it!

Inquiry

We look forward to receiving your opinions, comments, and letters regarding this column.
Contact:hulseminar@hulft.com

Experience HULFT Products.

Related Content