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

1. Byte counts include Ethernet and IP headers
2. Overhead = (Bytes Transmitted Server + Bytes Transmitted Client - 5000000)/5000000
3. This is a duplicate of the column in Table 1
4. FTP client counts do not include the frame that requested the file or the number of bytes (<100) in that frame
5. default chunk size of 8192 bytes was used
6. 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.