|
Options for Transferrintg Files From/To a VOS
Module |
Noah Davids
Stratus Support
Engineer
Stratus Technologies
VOS File Transfer Options
VOS supports a number of options to transfer files to/from another system.
This article briefly describes each option and details its strengths and
limitations.
First, a note on communication protocols.
VOS provides two TCP stacks, TCP_OS and STCP. In VOS releases
prior to release 15.0, both stacks are available as separate products. It is
also possible to run both stacks simultaneously, although interface cards can
be associated with only one stack and the PMC cards that go into the K470 and
K480 cannot be used with TCP_OS.
Starting with VOS release 15.0, only STCP is available, and it has been
integrated into VOS instead of being a separate product. Also in release 15.0,
there is no longer any Asynchronous hardware. Asynchronous connections must go
through a terminal or remote access server device and be converted to TCP.
Protocol
| VOS Server Available |
VOS client Available |
Recommendations |
Notes |
OSL |
TCP_OS/STCP |
TCP_OS/STCP |
Not recommended over WANs VOS to VOS only |
Integrated into VOS |
FTP |
TCP_OS/STCP |
TCP_OS/STCP |
Use this unless user ID/password or data security is an issue |
|
TFTP |
TCP_OS/STCP |
TCP_OS/STCP |
Use only as a last resort |
NFS |
TCP_OS/STCP |
no |
Not recommended over WANS Part of NFS/RPC Not available in VOS
15.0 or later |
|
SMB/CIFS |
STCP |
no |
|
Part of Samba introduced in VOS 14.4.0 |
HTTP |
STCP |
no |
|
Part of apache web server introduced in release 14.3 Not
available in VOS 15.0 or later |
SFTP |
STCP |
STCP |
Use when there is a need to prevent the data or the login password
from being read off the wire |
Part of OpenSSH OpenSSH 1.0 is available on VOS
14.7.0al OpenSSH 2.0 is available on VOS 15.1 |
PC_Connect |
Async |
No |
|
Part of PC_Connect Requires the pc_connect terminal emulator to
be running on a DOS machine (Windows command window is not
supported) Not available in VOS 15.0 or later |
Xmodem |
Async |
No |
|
Unsupported product available from ftp.stratus.com/vos/tools Should
work with most terminal emulators |
Table 1 - Summary of file transfer options and availability on
VOS
Open StrataLINK® (OSL)
Client availability:
|
Open StrataLINK is a VOS only protocol. All VOS systems come with
the OSL client (and server) built into the operating system. It doesn't
matter if you are using TCP_OS or STCP. If you look at the Stratus FTP
site (ftp://ftp.stratus.com/vos/networkyou
will see something called pc_osl. This is an OSL server for a PC running
Microsoft®
Windows® 95 or Windows NT
3.51/4.0. It hasn't been updated since it was written in 1997, and is
provided "as-is" with no guarantees. I mention it only to warn you that
it is not a supported product and you use it at your own
risk. |
Client ease of use:
|
Assuming that two systems have been configured to recognize each
other, you can transfer files just by using the copy_file command;
probably the easiest from the point of view of the person wanting to
transfer the file. |
|
Server (VOS) configuration:
|
While I would not call the OSL configuration task complex, it is not
trivial either. It requires creating at least one and possibly several
tables on each module. The information in each table across the modules
must agree. All modules in a VOS system are linked via OSL. Modules in
different systems may or may not be linked. |
|
Server (VOS) authorization and authentication:
|
Once a person has logged into one module and VOS has authenticated
him, he is authenticated on all modules in that system. The system
administrator has three choices for allowing users on a remote system
access to the local system:
- The remote user must be authenticated by the remote system (the
one first logged into). In other words, anyone authenticated on the
remote VOS system is taken as authenticated on the local system.
- The remote user must be authenticated by the remote system (the
one first logged into) and have a user ID that is registered on the
local system.
- The remote user must be authenticated by the remote system (the
one first logged into) have a user ID that is registered on the local
system, and the user must provide the local password via the
verify_system_access command.
Authorization to read and write
a file or directory is based on standard VOS
ACLs. |
Protocol efficiency:
|
OSL is NOT an efficient protocol for large file transfers. Instead
of asking for the entire file in one request, it requests it in 4K
chunks. After every chunk is transferred, the server waits for another
request. This type of "ping pong" protocol is extremely sensitive to
network latency. The throughput of transfers between modules on the same
subnet will not suffer, but throughput on high latency networks, for
example a WAN, will be significantly smaller - even if the bandwidth of
the network connection is high. |
File Transfer Protocol (FTP)
Client availability:
|
I don't like to use absolutes, but I think its safe to say that
there are File Transfer Protocol clients for every operating system and
hardware platform. These clients should all be compatible with both the
TCP_OS and STCP FTP daemons. Both TCP_OS and STCP also come with an FTP
client that should be compatible with another operating system's FTP
server. |
Client ease of use:
|
FTP is typically not seamlessly integrated into the client operating
system. You run a special command to start the client and special
requests to "get" or "put" a file from/to the server. There are some
clients that present an interface similar to the operating system they
are running. Typically, these work by parsing the directory contents
output the FTP daemon sends in response to a list request. These clients
will probably not work with a VOS daemon, although a few do. One I am
familiar with is WS_FTP from IPSWITCH (http://www.ipswitch.com/Products/WS_FTP/,
I'm sure there are others. |
Server (VOS)
configuration:
|
Neither the TCP_OS nor STCP FTP daemons require any special
configuration. All that is needed is to start them as a privileged
process. There are some configuration arguments mostly dealing with
security, but both daemons will run fine using the default values. The
STCP daemon is started from the start_stcp command macro and runs as a
separate process. The TCP_OS daemon is started by the inetd program. The
inetd program must be configured to start FTP, but the default
configuration file will do that so no changes are
needed. |
Server (VOS) authorization and
authentication:
|
After connecting to the server, a user must provide a user ID and
password. These are the standard VOS login IDs and passwords, so the
user must have a valid ID and password for the module he is connecting
to. Neither the TCP_OS nor STCP FTP daemons support anonymous login.
Once logged in, standard VOS ACLs for authorization apply.
|
Protocol efficiency:
|
FTP is the quintessential file transfer protocol. Once the request
is made, the only packets sent by the client receiving the file are TCP
layer acknowledgements. FTP works as well when going across a continent
as it does when going across a room. |
Knonw
issues:
|
The STCP FTP client may have problems when attempting to transfer
files to a system behind a file wall. Some network administrators
require that the client connect in the daemon in FTP passive mode. The
STCP FTP client does not support passive mode. The sftp-248 suggestion
has been entered to address this. TCP_OS does implement passive
mode. |
Trivial File Transfer Protocol (TFTP)
Client availability:
|
Like FTP, there are Trivial File Transfer Protocol clients for just
about all operating systems and hardware platforms, and like FTP, these
clients should all be compatible with both the TCP_OS and STCP FTP
daemons. The TCP_OS and STCP TFTP clients should likewise be compatible
with other operating system's TFTP servers. |
Client
ease of use:
|
TFTP was designed for use by other machines. It was originally, used
by diskless workstations to download images of configuration files and
operating systems. Many types of network hardware use it to download
configuration and executable files. TFTP was not designed for people to
use, however, it is possible for people to use
it. |
Server (VOS) configuration:
|
Both the TCP_OS and STCP daemons are started by the inetd process.
The TCP_OS and STCP inetd configuration files must be modified to start
inetd. The STCP config file has the command already in place and the
comment character just needs to be removed.
For TCP_OS, the command may not already be in place and have to be
added. If it is already there, you will have to remove the comment
character. It depends on the release of
VOS. |
Server (VOS) authorization and
authentication:
|
TFTP does not provide any authentication mechanism. This is one of
the big issues with TFTP and is a reason many system administrators do
not run it. Most servers have a mechanism to prevent a client for
requesting a file outside of specific directory trees. The STCP version
of TFTP does not. A client will be able to get any file on the system
that the daemon has access to. Putting a file on the server is
restricted to the >system>stcp_tftp_default directory. The daemon
runs under the user and group IDs of nobody.nobody.
You might think this is secure, but how many of your directories have
status or modify access for *.*? Or how many of your files have read
access for *.*? You can reduce the risks somewhat if you are running
STCP by starting TFTP up under TCP_Wrappers. TCP_Wrappers can restrict
what IP addresses or subnets are allowed to use TFTP. This is configured
in the inetd.conf file. Since VOS 15.0 systems with the NIO hardware
require that TFTP daemon be running, you should seriously consider
restricting the TFTP daemon to accept only requests from the NIO
hardware.
The TCP_OS version of the TFTP daemon will allow you
to recieve or put a file anywhere that the daemon has access. By
default, the daemon runs under the user and group IDs of
Overseer.SysAdmin. You can change this in the inetd.conf file.
You want to consider the security issues very carefully before
you run the TFTP daemon. |
Protocol
efficiency:
|
TFTP was designed for file transfers, but it was assumed that the
client was running with only a minimum TCP/IP stack. For that reason,it
uses UDP instead of TCP, and like OSL, it requests the file in chunks.
However, in TFTP the chunks are only 516 bytes. If a chunk is not
received or received corrupted, it will be requested again. The number
of retries is typically small (three to five). For all these reasons,
TFTP is not a good choice for transferring files across a WAN and only
marginal for transferring files over a LAN. Basically, the only time to
use TFTP is when it is the only thing
available. |
Knonw issues:
|
TFTP may have problems trying to transfer through a firewall. The
client uses a dynamic port number as its source port and the well known
TFTP port number (69) to contact the daemon. However, when the daemon
sends a file, it uses a dynamic port number for its source port and the
client's port number for the destination. The result is that the file is
transferred using two dynamic port numbers. |
Network File System (NFS)
Client availability:
|
All UNIX® systems have a
Network File System client capability. There are several different
clients available for Microsoft Windows systems. Neither TCP_OS nor STCP
provide an NFS client; while you can use a VOS file system from another
system using the VOS NFS server, you cannot use another operating
system's file system from a VOS system. |
Client ease
of use:
|
On UNIX® systems, a
special "mount" command needs to be executed before it can use a VOS
system's file system. This mount command can be executed manually, or
the system can be configured to do it automatically when the remote
system is booted or when the first reference is made. Once the VOS file
system is "mounted", a user can use all of the standard UNIX commands on
the files on the VOS system. From a user's perspective the files are on
the UNIX system that he is on.
Windows systems require a little
more effort. The Windows user IDs have to be mapped to UNIX style user
and group IDs. This is sometimes done via a specialized name server that
may or may not run on the client system. The "Windows Services for Unix"
set of tools from Microsoft can also be configured via special tables so
a name server does not have to be set up. Once set up, the mounted
directories look like a standard Windows network drive.
|
Server (VOS) configuration:
|
NFS configuration on VOS requires three tables — two to match UNIX
user and group IDs to VOS user and group tables and one to identify the
directories to be exported. In addition to the nfs_server, which must be
started, a "port mapping" server (portmap.pm) must be started. This
server is used to tell clients what port the NFS server is listening on.
For releases prior to VOS 15.0, there are STCP and TCP_OS
versions of both servers. The TCP_OS version will not be supported on
release 15.0 and there are no plans at this time to support the STCP
version of NFS on release 15.0. |
Server (VOS)
authorization and authentication:
|
The NFS client provides the user and group IDs of the user making
the request to the server. These IDs are mapped into a VOS user and
group name via tables on the server. Once the name and group are mapped,
standard VOS ACLs are applied using those names. If the names cannot be
mapped, a name of "nobody" is used. |
Protocol
efficiency:
|
Like TFTP, NFS uses UDP instead of TCP and requests the file in
chunks. The chunk size defaults to 8192 bytes and the server responds
with six (or 16, if client and server are on different subnets) packets.
This is both good and bad. It's good because it increases the efficiency
of the protocol. It's bad because if any of the six (16) packets fail to
make it back to the client the request must be issued again and all six
(16) packets resent. This chunking also makes the protocol sensitive to
network latency. UNIX clients can specify that they want to use a
smaller chunk. A chunk size of 1372 bytes should allow the entire chunk
to fit in one packet (512, if on different subnets) but this
significantly increases the sensitivity to network latency. So, like OSL
and TFTP, NFS is not a good protocol to use across a
WAN. |
Known issues:
|
The VOS NFS servers (either STCP or TCP_OS) do not appear compatible
with the "Windows Services for Unix" NFS client. The NFS client
identifies NFS servers by first sending a broadcast on port 111 to the
target subnet. It expects all hosts running a port map server to
respond. It then queries these hosts for the NFS server. The problem is
that the VOS port map server does not respond. The VOS NFS servers also
have a limited number of files that can be used at any one time. A UNIX
process that touches every file in a directory can result in quickly
exhausting those available files. |
Samba - Server Message Block (SMB) aka Common Internet File System
(CIFS)
Client availability:
|
Common Internet File System clients are built into every Microsoft
Windows system. The open source Samba product (http://www.samba.org/) provides a
client (and server) for many versions of UNIX and VOS. Neither the
TCP_OS nor STCP stacks provide clients, so there is no way for VOS to
mount a file system from another system using this protocol.
|
Client ease of use:
|
This is fully integrated into the Microsoft Windows system and is
seen as a network attached disk drive. It is treated exactly as a local
disk drive and folder. There are two ways for Windows to attach a
network drive. One is via the GUI and the other is using the "net use"
command in a command window. The "net use" command has the syntax:
|
net use : \\<SERVER>\<SHARE>
/user:<USER NAME>
<PASSWORD> | example
|
C:\ net use q: \\164.152.77.34\public /user:foo bar |
|
The command completed successfully. | Once
completed you can use the Windows GUI interface to access the folder
using the specified drive letter. When you want to stop using the
folder, use the GUI to "disconnect network drive". I have never seen the
Samba client for UNIX systems, so I cannot state how easy or difficult
it is to use. |
Server (VOS) configuration:
|
Server configuration is non-trivial. There are a lot of options
dealing with the way server presents files to the network and how the
server integrates with the existing Windows network environment. The
installation package comes with several example configurations to get
you started. It shouldn't take more than 15 minutes or so to get it
configured and running with the standard
shares. |
Server (VOS) authorization and
authentication:
|
Like NFS, the server needs a way to map the client windows names
into VOS names. Unlike NFS, the initial requests include a password, so
there is a password table that is independent of the VOS passwords. This
is the only confusing part of the configuration. The username_map file
maps the Windows user name into a VOS name and the smbpasswd file maps a
password to the VOS user name. However, the password is not the VOS
password; its the Windows password. Once authenticated with the windows
user name and password, the standard VOS ACLs are checked using the
associated VOS user name. |
Protocol efficiency:
|
The SMB/CIFS protocol implements both file and printer sharing. In
addition, it has gone through multiple revisions. This has made it
extremely complex, and I make no claims to be an expert. From looking at
traces, you can conclude that like TFTP and NFS, SMB/CIFS requests the
file in chunks. The chunks appear to range from 65 bytes to 65471 bytes.
I can't explain why the chunk size varies. Since SMB/CIFS uses TCP
instead of UDP, it is much more resistant to packet loss than TFTP or
NFS. Since the average chunk size is larger than OSL's 4K or NFS's 8K
(not to mention TFTP's 516 bytes), it is much less sensitive to network
latency than these other protocols. This would not be my first choice
for transferring a file across a WAN, but it appears to be a reasonable
option. |
HyperText Tranfer Protocol (HTTP)
Client availability:
|
I think its safe to say that all user workstations have a client
available. Microsoft Windows systems come with Internet Explorer built
in. Other clients are available for free download. Linux® distributions come with some form of
browser. Neither the TCP_OS nor STCP stacks have a
browser. |
Client ease of use:
|
Depending on the client, HTTP is very easy to use. There are
typically lots of configuration options, but the browser can be used
right out of the box. (Is there anyone who is not familiar with an
Internet web browser at this point?) |
Server (VOS)
configuration:
|
VOS has ported version 1.3.12 of the Apache web server. Server
configuration on VOS is not trivial, but the documentation is easy to
follow. Once the server is running setting up files for downloading is
very easy. Just enter the following line on the given web page.:
|
Text description of file <a
href="file_name"></a> | The above line
assumes that the file is in the same directory as the web page.
VOS does not support the options that allow uploads, so this protocol
can be used only for file downloads from the
server. |
Server (VOS) authorization and
authentication:
|
The web server does no authentication - everyone has access.
Authorization is based on the user ID of the process running the web
server - typically Apache.SysAdmin. So as long as Apache.SysAdmin has
access to the file and there is a page with a link to the file, it can
be downloaded. This is one way to allow anonymous access to files.
Instead of having anonymous login for the FTP server you can set up a
web page. |
Protocol efficiency:
|
Like FTP, the HTTP protocol requires just one packet that requests
the entire file. There is no chunking used as in TFTP, NFS or SMB/CIFS.
This makes it much less sensitive to network latency than these other
protocols. However, it does not always send the maximum sized packets
over the network. I believe that this due to its internal buffering when
it reads the file. |
Secure FTP (SFTP) |
Client availability: |
|
There are a number of Secure FTP clients for Microsoft Windows
systems, UNIX/Linux and MAC operating systems. Many of these are free,
although there are a number of commercially available products. VOS STCP
also includes an SFTP client. |
Client ease of use: |
|
Like FTP, SFTP clients operate as a separate process. It is not
seamlessly integrated with the operating system. |
Server (VOS) configuration: |
|
There is some configuration needed to configure the OpenSSL and
OpenSSH products, but nothing special for sftpd. |
Server (VOS) authorization and authentication: |
|
Like FTP, a user must provide a VOS login ID and a password. The
advantage of SFTP is that this information is encrypted before being
transmitted to the server, so that someone sniffing the network will not
be able to learn user IDs or passwords. Once logged in, all standard VOS
file access rules apply. |
Protocol efficiency: |
|
There is, of course, extra CPU cycles required to encrypt the data.
The protocol also requests the data in chunks. Chunk size is determined
by the client, but I am not sure how. In my test cases the size of 4,200
bytes was used. So SFTP not only has some sensitivity to network
latency, but also has the extra overhead of encryption.
|
pc_connect/pc_file_transfer
|
The pc_connect product is a terminal emulation program for Microsoft
DOS and a set of VOS PMs, one of which is pc_file_transfer. The
pc_file_transfer can, as its name suggests, transfer files between a PC
and VOS. While the emulation program can be run under DOS or in a CMD
window under Microsoft Windows, it is only supported under DOS. Running
it under Microsoft Windows may produce erratic behavior, including
hanging the emulation. Doing a file transfer when the emulation is
running in a CMD window may result in file
corruption. |
Xmodem
|
Available on the anonymous FTP site (ftp://ftp.stratus.com/), in the
vos/tools directory, is source code for an xmodem command. Many (most,
all?) terminal emulation programs have the ability to transfer files
using the xmodem protocol. Unfortunately, the CAC cannot officially
support this protocol. |
Protocol |
Frames Transmitted Server |
Frames Transmitted Client |
Bytes (1) Transmitted Server |
Bytes (1) Transmitted Client |
Overhead (2) |
Recommendations (3) |
OSL |
3796 |
3074 |
5297656 |
353989 |
13.0329% |
Not recommended over WANs VOS to VOS only |
FTP |
3464 |
1742 |
5250426 (4) |
101040 |
7.02932% |
Use this unless user ID/password or data security is an issue |
TFTP |
9863 |
9863 |
5542660 |
631232 |
23.47784% |
Use only as a last resort |
NFS (5) |
3667 |
615 |
5205704 |
119262 |
6.49932 |
Not recommended over WANS Part of NFS/RPC Not available in VOS
15.0 or later% |
SMB/CIFS |
3844 |
2091 |
5264507 |
144456 |
8.17926% |
|
HTTP |
4694 |
2756 |
5284940 |
176588 |
9.23056% |
|
SFTP (6) |
3743 |
2530 |
5344690 |
430118 |
15.49616% |
Use when there is a need to prevent the data or the login password
from being read off the wire |
Table 2 - Efficiency when transferring a 5,000,000 byte file from a
VOS server to a clientNotes
- Byte counts include Ethernet and IP headers
- Overhead = (Bytes Transmitted Server + Bytes Transmitted Client -
5000000)/5000000
- This is a duplicate of the column in Table 1
- FTP client counts do not include the frame that requested the file or
the number of bytes (<100) in that frame
- default chunk size of 8192 bytes was used
- These overhead statistics are a little inflated compared to the others
because the segment size was 1400 instead of 1460. This was due to the
network I was using and not anything inherent in SFTP
StrataLINK is a registered trademark of Stratus Technologies Bermuda Ltd.
Microsoft and Windows are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
UNIX is a registered trademark of the Open Group in the United States and
other countries.
The registered trademark Linux is used pursuant to a sublicense from the
Linux Mark Institute, the exclusive licensee of Linus Torvalds, owner of the
mark on a worldwide basis.
All other trademarks and registered trademarks are the property of their
respective owners.