Scannex ip.buffer User Manual
© UK 2007-2021 Scannex Electronics Ltd. All rights reserved worldwide.
10.4. FTP Server
The ip.buffer can collect data from devices that perform an FTP push into the buffer. e.g.
Cisco Call Manager 5.
The files pushed into the ip.buffer are stored into the single storage area for the channel.
You can choose whether to apply a marker around the file. This is especially useful in
rebuilding the files at the central site (particularly if the memory wraps and you lose the
beginning marker).
FTP Server
Username
The ip.buffer has a single FTP server for all activities (collection
and delivery) and so you need to enter a unique username
to distinguish the activity.
Obviously, you will need the same username and password that is
programmed into the sending device.
[_channel1]
,
[_channel2]
, etc
Password
The password.
[password]
Timeout
A timeout (in minutes) for the FTP client. If the client does not
send an FTP command within this time period the
ip.buffer will disconnect the session – if the client
“hangs”.
“
0
” = disable the timeout.
[0]
File Markers
“
None
” – just stores the files as-is.
“
Use {ftp…}
” – applies the {ftp} begin and end markers
“
Use {ftp…}+CRLF
” – applies the {ftp} begin and end markers
on a separate line.
[Use {ftp…}]
The File Markers are in the form:
{ftp begin,
time
,
ip
,
file
}
Where:
“time” is the date and time (local buffer time) in the form yyyymmddhhmmss.
“ip” is the IP address of the FTP client
“file” is the filename the client is about to push
The file’s data is then processed through the ip.buffer’s record detector (which can include
further modification such as adding a date time prefix etc). At the end of the file transfer
a suffix is appended to the memory store:
{ftp end,
time
,
ip
,
file
}
If the FTP client aborts the transfer for any reason, then the following suffix is appended
instead:
{ftp failed,
time
,
ip
,
file
}
Page 69
Scannex ip.buffer User Manual
© UK 2007-2021 Scannex Electronics Ltd. All rights reserved worldwide.
10.4. FTP Server
The ip.buffer can collect data from devices that perform an FTP push into the buffer. e.g.
Cisco Call Manager 5.
The files pushed into the ip.buffer are stored into the single storage area for the channel.
You can choose whether to apply a marker around the file. This is especially useful in
rebuilding the files at the central site (particularly if the memory wraps and you lose the
beginning marker).
FTP Server
Username
The ip.buffer has a single FTP server for all activities (collection
and delivery) and so you need to enter a unique username
to distinguish the activity.
Obviously, you will need the same username and password that is
programmed into the sending device.
[_channel1]
,
[_channel2]
, etc
Password
The password.
[password]
Timeout
A timeout (in minutes) for the FTP client. If the client does not
send an FTP command within this time period the
ip.buffer will disconnect the session – if the client
“hangs”.
“
0
” = disable the timeout.
[0]
File Markers
“
None
” – just stores the files as-is.
“
Use {ftp…}
” – applies the {ftp} begin and end markers
“
Use {ftp…}+CRLF
” – applies the {ftp} begin and end markers
on a separate line.
[Use {ftp…}]
The File Markers are in the form:
{ftp begin,
time
,
ip
,
file
}
Where:
“time” is the date and time (local buffer time) in the form yyyymmddhhmmss.
“ip” is the IP address of the FTP client
“file” is the filename the client is about to push
The file’s data is then processed through the ip.buffer’s record detector (which can include
further modification such as adding a date time prefix etc). At the end of the file transfer
a suffix is appended to the memory store:
{ftp end,
time
,
ip
,
file
}
If the FTP client aborts the transfer for any reason, then the following suffix is appended
instead:
{ftp failed,
time
,
ip
,
file
}
Page 69
