| |
|
|
|
3 REFERENCE
3.1 LIBRARY FUNCTIONS
3.1.1 Image data transfer
Sends the data in chunks to the requestor for these data. If data compression is requested the function will see to that the appropriate compression algorithm is applied on the data.
Receives the data packets and hands these over to the calling application. For each packet it ischecked if the type of message is correct. If data is compressed the function decompresses the data.
The following functions are the compression algorithms supported by dxf. They are mentioned merely, since they might be usefull in other contexts.
Performs the actual compression by means of Lempel-Zivs algorithm.
Performs a compression of a data buffer using an unknown method.
Performs decompression of a buffer compressed with dxfFinCompress().
3.1.2 File transfer
Called from C/C++ code to transfer a file as described in 2.6. The application using this function must link to the library dxfTransf.
Called from Tcl code to transfer a file as described in 2.6. The application using this function must link to the library dxfPublic.
3.2 TEST PROGRAMS
The dxfBenchmark test program is used to test the transfer rate in an easy manner. It returns the effective transfer rate measured transferring data between two test applications.
3.3 MAN PAGES FOR LIBRARY FUNCTIONS
3.3.1 dxfFinCompress(3)
The subroutine compresses the buffer pointed to by "inputBuf" and stores
the compressed bytes in the buffer pointed to by "outputBuf". Both buf-
fers should be allocated by the calling process. The length of the
uncompressed buffer should be given in as the "inputBufLen" parameter.
The method used by the algorithm is not known but was originally
written by a fin, Jussi Puttonen, who used it as an entry for the
Dr Dobbs Compression Contest.
inputBuf IN Pointer to the buffer containing the uncompressed data.
This buffer should be allocated a length at least one
longer than the data length.
inputBufLen IN Length of the input data buffer in bytes.
outputBuf IN Pointer to the buffer in whihc the compressed data will be
stored.
The output buffer should be somewhate bigger than the input buffer in
case the compression fails to avoid segmentation errors.
Futhermore the length of the input buffer should be at least one longer
than the length of data.
The subroutine can maximum handle buffers of 65 kB.
3.3.2 dxfFinDecompress(3)
The subroutine decompresses a buffer compressed with dxfFinCompress().
The data to be compressed must reside in the buffer "inputBuf" and the
data to be decompressed in the "outputBuf" buffer. Both buffers must be
allocated by the calling process. The length of the input buffer should
be at least one longer than the length of the data, and the output buf-
fer sufficiently long to store the decompressed data in.
The algorithm used is not known.
inputBuf IN Pointer to the buffer containing the compressed data.
inputBufLen IN Length of the input buffer in bytes.
outputBuf IN Buffer in which the decompressed data is stored.
Make sure that the buffer in which to store the decompressed data is
sufficiently large to hold these since otherwise a segmentation error
will occur. The length of the input buffer should be at least one longer
than the length of the data.
The subroutine can maximum handle buffers of 65 kB.
3.3.3 dxfLempZiv(3)
The function compresses the input buffer by means of Lempel-Ziv's algo-
rithm, which in short terms looks for repeated strings and replaces
these with pointers to a reference.
Since this is a piece of public domain software not implemented in-
house, the source file does not comply completely with the VLT Program-
ming Standards, when it comes to variable names, etc.
It should be mentioned that the algorithm works best on small files,
with the optimal performance on files of size 32 K.
InIma IN Pointer to the buffer containing the uncom-
pressed data.
OutIma OUT Pointer to the buffer in which the compressed
data will be stored.
length IN Length (in bytes) of the input image buffer.
do_decomp IN Indicates if a compression or a decompression
of the input buffer should be performed. Two
symbols are provided, "dxfDO_COMPRESSION" and
"dxfDO_DECOMPRESSION".
Although the compression usually yields a buffer with (much) fewer ele-
ments than the input buffer, there should be allocated some extra space
for the output image buffer to avoid overflow in case the compression
does not succed very well.
#include "dxf.h"
char detData[32768];
char comprData[32768 + 1024];
long detDataLen;
long comprDatalen;
do
{
... get detector data and length of buffer ...
comprDataLen = dxfLempZiv(detData,
comprData,
detDataLen,
DO_COMPRESSION);
... save data, transmit data ... ...
}
while (... detector data is coming ...);
3.3.4 dxfRecvData(3)
#include "dxf.h"
ccsCOMPL_STAT dxfRecvData(dxfDATA_TYPE transferType,
dxfHEADER_INFO *headerMsg,
dxfRECV_DATA_INFO *data,
dxfTRAILER_INFO *trailerMsg,
msgTIMEOUT timeOut,
vltLOGICAL *done,
dxfCON_HANDLE *conHandle,
ccsERROR *error)
dxfRecvData() is called by the process that is ready to receive
incoming data. Remark however that prior to that, a command must have
been sent by this process requesting these data.
A data transfer is split into three parts:
1. Header Transfer: Could typically be transfer of FITS information.
2. Data Transfer: The actual transfer of data.
3. Trailer Transfer: Could typically be transfer of FITS information.
It is possible to receive all three categories of data with one call to
dxfRecvData() - the "transferType" parameter must then be
dxfALL_DATA_TYPES. If the three categories of data should be received
individually, the macro dxfINDIVIDUAL must be used.
The Header and Trailer Data are always received with maximum one call to
dxfRecvData() each. dxfRecvData() allocates itself enough memory to store
the data received. Note that this is static memory, which will be
overwritten by the next reception of Header/Trailer Data.
The Data can be received with either one call to dxfRecvData() or as
individual buffers as they come in. If the member "recvType" in the
dxfRECV_DATA_INFO structure is dxfSINGLE_MSG, dxfRecvData() returns a
pointer to the sequentially next block of data. If all data should be
received, dxfALL_MSG should be the value. If the "buffer" pointer in
the dxfRECV_DATA_INFO points to zero it is the responsibility of
the calling application to copy these data to local memory, as subsequent
calls to dxfRecvData() will overwrite the previous received buffer.
When the data transfer is finished, the "done" parameter will be ccsTRUE.
The following five combinations are possible when receiving data:
1. Receive all three parts in one batch.
The "transferType" parameter must be dxfALL_DATA_TYPES.
2. Receive all three parts individually.
3. Receive only Header and Data.
4. Receive only Data and Trailer.
5. Receive only Data.
For the individual reception of the data types, the "transferType" must
be dxfINDIVIDUAL. The "deCompress" and the "recvType" member in the
dxfRECV_DATA_INFO structure must be initialized properly. The
application must continue to perform calls to dxfRecvData() untill
the "done" flag becomes ccsTRUE.
The "bufLen" and "send" members in the dxfHEADER_INFO/dxfTRAILER_INFO
structures indicates if any data was received for this type of data.
The "done" flag in the structure for the Header, the Data and the Trailer,
indicates when this batch of data has been received.
Note that only the actual Data can be compressed. The Header and Trailer
Data blocks are always received uncompressed.
If the other side sends off an Error Reply e.g. to terminate the data
transfer (ABORT), the function will return with the CCS Error Structure
set with the error information as set by the sending side. The following
must be applied for handling the error:
1. The Error Number must be the same on the sending and the receiving
side.
2. The Run Time Parameter for the error is not allowed to contain any
variable fields.
At the first call to dxfRecvData() the members in the dxfCON_HANDLE
structure (hostName, envName, procName) must be set.
At the first data transfer the dxfSendData() and dxfRecvData() functions
create a socket connection between them through which data is sent.
A timeout of currently 10 s is given to create the socket connection.
The protocol for initializing the data transfer could typically be:
1. The receiving process sends off a "SENDATA" command to the
sending process.
2. The sending process receives and parses the command and sends
a CCS reply and set subsequently the flags of the
Header, Data and Trailer structures and calls dxfSendData().
3. When the receiving process receives the reply it sets the
the flags of the Header, Data and Trailer structures and calls
dxfRecvData().
In order to create the socket connection between the sending and
receiving side a dummy data transfer could be carried out before the
first exposure. This dummy data transfer could be carried out when the
system is initialized (the INIT command is issued).
If one of the processes sending/receving is restarted, or the connection
gets lost for other reasons, it is automatically build up again.
transferType IN Defines if data should be received as one batch or
as individual packages. Macros for the handling are:
dxfALL_DATA_TYPES and dxfINDIVIDUAL.
headerMsg OUT Specifies the possible Header Data received. If no
Header Data was received, the "bufLen" member will
be 0, and the "send" member ccsFALSE.
data IN/OUT Specifies the conditions for receiving the data and
contains information about the data received. The
members are as follows:
->deCompress IN Indicates if a compressed data buffer received
should be decompressed or simply handed over to
the calling application. Used a.o. when the data
buffer is forwarded compressed. Two macros
are provided for handling this parameter; these
are dxfDECOMPRESS and dxfDONT_DECOMPRESS.
NOT SUPPORTED IN VERSION 2.0.
->recvType IN Indicates if data should be received as individual
messages or in one batch. (Macros:
dxfSINGLE_MSG and dxfALL_MSG.
->expLen OUT Amount of data as expected by dxfRecvData()
(bytes).
->lenRecv OUT Accumulated amount of data actually received
(bytes).
->buffer IN/OUT A pointer to the buffer containing the data.
This buffer always contains uncompressed data.
The buffer is local and it is up to the calling
application to take further care of the data
(save in files, memcpy()). Before each call
to dxfRecvData() make sure this buffer points to
NULL, since in a later release it will be possible
to let DXF receive the data directly into a buffer
provided by the user.
->bufLen OUT The length of the last buffer returned by
dxfRecvData(). If data is received in one batch,
this equals "lenRecv".
->comprBuf OUT Points to buffer (possibly) containing compressed
data. The buffer is only filled if data is received
compressed.
->comprBufLen OUT Indicates the length of the possible compressed
data. The member is 0 if data is received
uncompressed.
->compressInfo OUT Structure telling which type of compression was
used - if any.
trailerMsg OUT Specifies the possible Trailer Data received. If no
Trailer Data was received, the "bufLen" member will
be 0, and the "send" member ccsFALSE.
timeOut IN Number of ms to wait for a single CCS/LCC message
before timing out. Note that dxfRecvData() may block
for more than the timeout time specified if e.g.
data is received in one batch. The timeout is for
the individual access to the CCS Message System.
conHandle IN Contains information about the sending process.
must be initialized before the first call to
dxfRecvData() but a local copy of the information
is made so it need not be preserved thougout the
usage of DXF. The members of the structure are
hostName This is the name of the network interface
to be used. This is not necessarily the
same name as the sending host, since
several network interfaces may be
installed on the same host. The name is
the one on the receiving host.
envName The name of the RTAP environment in which
the sending process is running.
procName The RTAP process name for the sending
process.
error OUT CCS Error Structure indicating errors possibly
occurring.
SUCCESS On success.
FAILURE The following errors are defined:
dxfERR_RECV An error occurred while receiving a
CCS/LCC message.
dxfERR_RECEIVE_HEADER Header receive failed
dxfERR_RECEIVE_DATA Data receive failed
dxfERR_RECEIVE_TRAILER Trailer receive failed
dxfERR_MSG_TIMEOUT Receiving message had a timeout.
dxfERR_OBI_RECV Received an obituary message.
dxfERR_PARSE Error occurred while parsing message.
dxfERR_DECOMPR Error occurred while decompression a
message.
dxfERR_ERROR_REPLY Received an error reply message.
dxfERR_UNKNOWN_MSG Received an unknown message.
dxfERR_ALLOC_MEM Could not allocate the desired
amount of memory.
dxfERR_PREMAT_LAST_REP A CCS Last Reply was received
prematurely.
The version of June 1996 and later versions of the DXF library are not
compatible with earlier versions. The interface of dxfRecvData() has
changed, and raw sockets are used for the transmission rather than the
CCS Message System.
Calling the function after it has returned with a FAILURE, it starts out
on a new transfer session.
In this version, if the socket connection is lost, there will be no
automatic re-connection attempts.
The "buffer" pointer of the "data" structure must be initialized to NULL
in this release. In a later release it will be possible to let DXF
receive the data directly into a user provided buffer.
The maximum size of a message sent by DXF is dxfMSG_TRANSFER_SIZE, which
is dividable through 8 bytes to ensure that only complete pixel values
are received.
* Transfer data from process "DataXferLcu" running in environment "lte55".
* The local host (the LAN interface to use) is "te16".
*
* Receive the 3 Data Types individually, receive the Data in
* individual buffers
#include "dxf.h"
char dataBuf;
dxfCON_HANDLE conHandle;
dxfHEADER_INFO headerMsg;
dxfRECV_DATA_INFO data;
dxfTRAILER_INFO trailerMsg;
msgTIMEOUT timeOut;
vltLOGICAL done;
ccsERROR error;
vltUINT32 bytesRecv;
... send off command requesting for data
data.recvType = dxfSINGLE_MSG;
if (firstTransfer)
{
strcpy(conHandle.hostName, "te16");
strcpy(conHandle.envName, "lte55");
strcpy(conHandle.procName, "DataXferLcu");
}
bytesRecv = 0;
do
{
if (dxfRecvData(dxfINDIVIDUAL,
&headerMsg,
&data,
&trailerMsg,
10000,
&done,
&conHandle
&error) == FAILURE)
... error processing
if (bytesRecv < data.lenRecv)
{
bytesRecv = data.lenRecv;
if (fwrite(data.buffer, sizeof(char),
(size_t)data.bufLen, filePtr) != data.bufLen)
... error processing
}
}
while (done == ccsFALSE);
if (headerMsg.send == ccsTRUE)
... process the Header Data
(could also be done already after first return from dxfRecvData())
if (trailerMsg.send == ccsTRUE)
... process the trailerData
3.3.5 dxfSendData(3)
#include "dxf.h"
ccsCOMPL_STAT dxfSendData(dxfDATA_TYPE transferType,
dxfHEADER_INFO *headerMsg,
dxfSEND_DATA_INFO *data,
dxfTRAILER_INFO *trailerMsg,
dxfORGCALL *origCaller,
ccsERROR *error)
dxfSendData() is used to send (detector) data to a requestor for these
data. A data transfer is split into three parts:
1. Header Transfer: Used normally for sending text buffers, though could
also be used for binary data.
Could typically be transfer of FITS information.
2. Data Transfer: The actual transfer of data. Binary data.
3. Trailer Transfer: Used for sending for sending text buffers, though
could also be used for binary data.
Could typically be transfer of FITS information.
Header and Trailer Data must be sent in one batch each. I.e. only one call
to dxfSendData() for each, whereas the actual Data can be send as
individual buffers, or in one batch if desirable.
It is possible to send all three categories of data with one call to
dxfSendData() - the "transferType" parameter must then be
dxfALL_DATA_TYPES. If the three categories of data should be sent
individually, the macro dxfINDIVIDUAL must be used.
Before making the 1st call to dxfSendData(), the "send" parameter in the
structures pointed to by "headerMsg", and "trailerMsg" must be set
to indicate if it is the intention to send any Header/Trailer Data.
"send = ccsTRUE" indicates that the data should be sent. Furthermore
if Header Data and/or Trailer should be sent, the size in bytes of these
must be specified.
By the 1st call to dxfSendData() the "totalBufLen" member and the
"compressInfo" structure in the dxfSEND_DATA_INFO structure, pointed
to by "data" must be set as well.
The information in the Header, Data and Trailer structures will be
stored internally in the function and it is not necessary to use the
same structures all the way through the transfer.
Data can be sent in the following ways:
1. All three types in one batch (all parameters in the dxfHEADER_INFO,
dxfSEND_DATA_INFO and dxfTRAILER_INFO structures must be initialized
in this case). "transferType" must be dxfALL_DATA_TYPES.
2. Send the three message types individually. At least three calls to
dxfSendData() must be made specifying "transferType" to dxfINDIVIDUAL.
Data can be sent with several calls to dxfSendData().
3. Send only Header Data and Data but no Trailer Data
(trailer->send = ccsFALSE). At least two calls must be made to
dxfSendData(), specifying "transferType" to dxfINDIVIDUAL. Data can be
sent with several calls to dxfSendData().
4. Send no Header Data but Data and Trailer (header->send = ccsFALSE).
At least two calls must be made to dxfSendData(), specifying
"transferType" to dxfINDIVIDUAL. Data can be sent with several calls
to dxfSendData().
5. Send only Data (header->send = trailer->send = ccsFALSE). "transferType"
must be dxfINDIVIDUAL. Data can be sent with several calls to
dxfSendData().
It is possible to send an Error Reply across by setting the CCS Error
structure "error" using errAdd(). In this case the function will send
the Error Number across, and will reset its internal variables for
handling that connection. The error will be sent across with the
information as set by the calling application. The error structure is
reset before returning. If an error occurs while sending the error reply,
the error structure is set accordingly as is the normal procedure.
This can be used to unblock the dxfRecvData() function e.g. in case
the exposure is aborted.
The following must be applied for handling the error:
1. The Error Number must be the same on the sending and the receiving
side.
2. The Run Time Parameter for the error is not allowed to contain any
variable fields.
At the first data transfer the dxfSendData() and dxfRecvData() functions
create a socket connection between them through which data us sent.
A timeout of currently 10 s is given to create the socket connection.
If one of the processes sending/receving is restarted, or the connection
gets lost for other reasons, it is automatically build up again.
In order to give enough time for the sender and the receiver to re-establish
lost connection, if the timeout of the receiver is known to the sender,
set the following two parameters to:
- origCaller->receiveTimeout = <receiver timeout in ms>
- origCaller->useTimeout = ccsTRUE
The maximum size of a message sent by DXF is dxfMSG_TRANSFER_SIZE, which
is dividable through 8 bytes to ensure that only complete pixel values
are received.
transferType IN Can be either dxfALL_DATA_TYPES - send all three types
in one batch, dxfINDIVIDUAL - send at least Data and/or
maybe the Header and the Trailer.
headerMsg IN Pointer to dxfHEADER_INFO structure containing
information about the Header Data. The members must be
handled in the following way:
->buffer IN Points to buffer containing the Header Data. Must be
allocated by the calling application.
->send IN Indicates if the Header Data should be sent or not.
ccsTRUE = send.
->bufLen IN The length of the Header Buffer (bytes) to send
by the next call to dxfSendData().
data IN Pointer to dxfSEND_DATA_INFO structure containing
information about the Data. The members are as follows:
->buffer IN Pointer to buffer to send by the next call to
dxfSendData(). Must be allocated by the
calling application.
->bufLen IN Length of buffer to send (in bytes) by the next call
to dxfSendData().
->totalBufLen IN Total amount of data to send. Must also be set if the
three data types are sent individually.
->compressInfo IN Contains information about the compression properties.
See description below. Note, that only the actual Data
can be compressed.
trailerMsg IN Pointer to dxfTRAILER_INFO structure containing
information about the Trailer Data. See explanation of
"headerMsg" structure.
origCaller IN Pointer to a structure indicating the originator of the
request for data. if the timeout of the receiver is known
to the sender, set the following two parameters to:
->receiveTimeout = <receiver timeout in ms>
->useTimeout = ccsTRUE;
Otherwise,
->useTimeout = ccsFALSE;
error OUT An error structure to pass back the type of a possible
error which occurred. Can be used to send an Error Reply
across e.g. to terminate (ABORT) a data transfer.
The dxfCOMPRESS structure in the dxfSEND_DATA_INFO structure,
contains a member (request) which should always be initialized also
when not using compression. The possible values for the request
parameter are:
dxfNO_COMPR: Data will not be compressed. If uncompressed data is
forwarded uncompressed, this value should be used.
dxfLEMP_ZIV: Employs an implementation of the Lempel-Ziv algorithm
to perform the data compression.
dxfFIN_COMPR: A compression/decompression implementation based
on an unknown algorithm.
dxfSHORT: Selects the compression method which gives the best
(shortest) result. Leaves it up to dxf to select a
method.
dxfFAST: Selects the compression methods which gives the fas-
test compression, but maybe not the best result.
dxfFORWARD_COMPR: Used to indicate that data should be forwarded
compressed on the receiving side, and therefore should
not be recompressed. It is only possible to forward one
compressed buffer at a time. NOT supported in version
2.0.
SUCCESS When data was sent succesfully.
FAILURE If the message system failed to bring the message across. In
this case the ccsERROR structure is set. The following error
codes can be returned:
dxfERR_TRANSFER_HEADER Header transfer failed
dxfERR_TRANSFER_DATA Data transfer failed
dxfERR_TRANSFER_TRAILER Trailer transfer failed
dxfERR_CONN_SEND_HEADER Header transfer failed. Failed to
reconnect after lost connection.
dxfERR_CONN_SEND_DATA Data transfer failed. Failed to
reconnect after lost connection.
dxfERR_CONN_SEND_TRAILER Trailer transfer failed. Failed to
reconnect after lost connection.
dxfERR_SEND Error in replying to source.
dxfERR_SEND_INIT_MSG Could not send the DXF data transfer
initialization message.
dxfERR_SEND_REPLY Could not send a reply.
dxfERR_COMPR Could not compress data.
When calling dxfSendData() after a request has been received, all messages
should be sent either compressed or uncompressed. It is however possible
to change the compression method to be used.
Calling the function after it has returned with a FAILURE, it starts out
on a new transfer session.
Note that if the CCS Error Structure is not reset calling the function
(if it contains an error), the function will send off an Error Reply.
Note that the function will take up a stack size of more than 30 kB.
The maximum size of a message sent by DXF is dxfMSG_TRANSFER_SIZE, which
is dividable through 8 bytes to ensure that only complete pixel values
are received.
* Send the 3 Data Types individually, Send the Data as
* individual buffers.
* Assume 10000 ms timeout on the receiver side.
#include "dxf.h"
char hdData[4096];
char dataBuf[8192];
char trailBuf[4096];
dxfHEADER_INFO headerMsg;
dxfSEND_DATA_INFO data;
dxfTRAILER_INFO trailerMsg;
dxfORGCALL origCaller;
ccsERROR error;
.. receive request for data
.. generate Header Data
headerMsg.buffer = hdData;
headerMsg.bufLen = sizeof(hdData);
headerMsg.send = ccsTRUE;
data.totalBufLen = (1024 * 1024);
data.compressInfo.request = dxfNO_COMPR;
trailerMsg.buffer = trailBuf;
trailerMsg.send = ccsTRUE;
trailerMsg.bufLen = sizeof(trailBuf);
origCaller.receiveTimeout = 10000;
origCaller.useTimeout = ccsTRUE;
* Send the Header Data
*
if (dxfSendData(dxfINDIVIDUAL,
&headerMsg,
&data,
&trailerMsg,
&origCaller,
&error) = FAILURE)
... error processing
* Send the Data
*
do
{
... get the data
data.buffer = dataBuf;
data.bufLen = sizeof(dataBuf);
if (dxfSendData(dxfINDIVIDUAL,
&headerMsg,
&data,
&trailerMsg,
&origCaller,
&error) = FAILURE)
... error processing
}
while (more data to sent);
* Send the Trailer Data
*
if (dxfSendData(dxfINDIVIDUAL,
&headerMsg,
&data,
&trailerMsg,
&origCaller,
&error) = FAILURE)
... error processing
3.4 MAN PAGES FOR TEST PROGRAMS
3.4.1 dxfBenchMark(1)
The DXF Benchmark test is used to test the transfer rate between two
processes via a certain connection. The two processes can be located
on different hosts, or they can be located in different RTAP environments
on one host, or in one RTAP environment on one host.
When transferring between two hosts, it is assumed that
o The same versions of DXF is installed properly on both platforms
and can be accessed using remsh calls.
o That the environment(s) involved are already are running.
o That the user on the local host is trusted on the remote host
(i.e. that he can run remsh without giving password).
o That the user on the remote host has bash as log-in shell.
The utility gives out the transfer rate measured.
<local host> Hostname of the host to which the data should be
sent. Remark that for hosts with several network interface
cards and IP-addresses, each address corresponds to a
different hostname; for such hosts one can this way select
which network interface (and route) has to be exercised.
<local env> Name of local (RTAP) environment in which the receiving
process is running.
<remote host> Host name of the machine from where the data is sent.
Remark that for hosts with multiple network interface
cards, the actual interface used for the transfer will
depend on <local host> and the gateway/routing set-up
on <remote host>, i.e. it is not directly determined by
the <remote host> argument.
The <remote host> may be the same as the receiving host
i.e. if data is sent within one machine.
<remote env> Name of remote (RTAP) environment in which the sending
process is running.
[-size <size>] Size of data to send. If not specified, the default size
is 1 MB.
[-noRuns <no>] Number of tests to carry out with varying size of data
handed over to the sending DXF function. This can be used
to find the optimum size of data packages to send. If
5 is specified, data will be handed over as 10000,
20000, 30000, 40000 and 50000 bytes.
In this version it is not possible to use the compression facility while
transferring.
In case there are problems with the remsh into the remote host, one can
always start "dxfTestSend" in the background on this remote host, and then
try again dxfBenchmark from the local host.
3.5 MAN PAGES FOR THE FILE TRANSFER MECHANISM
3.5.1 dxfFileTransfer
dxfFileTransfer(const char * sourceFileName,
const char * destinationEnvName,
const char * destinationFileName,
const char * sourceFilePath,
const char * destinationFilePath,
ccsERROR * error)
This procedure is used in a C/C++ executable to transfer a
file between two VLT environments hiding all commands sending.
The pair of client/server processes used for such a purpose
must be already registered whitin CCS (see the corresponding man
pages for "dxfFilesend" and/or "dxfFileReceive").
Allowed arguments:
sourceFileName IN the name of the file to be transferred
without path.
destinationEnvName IN destination environment where the above
specified file should be transferred to.
destinationFileName IN the name of the saved file (if this
parameter is NULL, the source file name
is used to store the file in the
destination environment).
sourcePath IN path of the source file. If NULL,
the file is retrieved from
$INS_ROOT/SYSTEM/DETDATA.
destPath IN path where the destination file is saved.
If NULL, the file is stored in
$INS_ROOT/SYSTEM/DETDATA of the destination
environment.
error OUT an error structure to pass back the type of
possible error which occurred.
SUCCESS after the data transfer is completed and the file is
saved succesfully.
FAILURE if an error occurs. In this case the ccsERROR structure
is set.
The processes (dxfFileSend/dxfFileReceive), which
actually take care of the transfer mechanism, must be already
active in their respective environment.
ccsERROR error;
const char * sourceFile = "fileToTransfer.bin";
const char * destEnv = "XXXX";
const char * destFile = "receivedFile.bin";
const char * sourcePath = getenv("PWD");
const char * destPath = "~yyyy/zzzz/";
if ( dxfFileTransfer(sourceFile,destEnv,
destFile,sourcePath,destPath,&error) == FAILURE ) {
errDisplay(&error,ccsTRUE);
ccsExit();
return 1;
}
3.5.2 dxfFileTransf
This procedure is used in a Tcl script to transfer a file between
two VLT environments. The pair of client/server
processes used for such a purpose must be already registered
whitin CCS (see the corresponding man pages for "dxfFilesend" and/or
"dxfFileReceive").
Allowed arguments:
sourceFile (mandatory) the name of the file to be transferred
without path.
destEnv (mandatory) destination environment where the above
specified file should be transferred to.
destFile (optional) the name of the saved file (if this
parameter is not set, the source file name
is used to store the file in the
destination environment).
sourcePath (optional) path of the source file. If not set,
the file is retrieved from
$INS_ROOT/SYSTEM/DETDATA.
destPath (optional) path where the destination file is saved.
If not set, the file is stored in
$INS_ROOT/SYSTEM/DETDATA of the destination
environment.
The processes (dxfFileSend/dxfFileReceive), which
actually take care of the transfer mechanism, must be already
active in their respective environment.
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|