NC

S TAT E

UNIVERSITY

TTCPW
Windows NT/95 Port of TTCP

Gregg G. Seipp

ABSTRACT

This paper outlines the Windows NT/95 port of TTCP. It includes porting issues, an example session, and instructions on how to compile and install the program. Appendix A includes the complete original manual for TTCP.
TA B L E O F C O N T E N T S

Abstract...............................................................................................................1 Table of contents.................................................................................................1 Introduction.........................................................................................................1 Porting Issues and solutions................................................................................2 Sockets................................................................................................................2 Timing..................................................................................................................3 ERRATA................................................................................................................3 Example runs.......................................................................................................3 Installation...........................................................................................................4 Compilation.........................................................................................................4 Appendix A..........................................................................................................5 Original TTCP documentation..............................................................................5 Bibliography.........................................................................................................8

INTRODUCTION

TTCPW is a port of TTCP, designed to run on the Windows NT/95 platforms. It is designed to keep the source code as similar to the original program as possible. As such, I made as few changes as practical. These changes included adding Win32 specific functions, changing existing calls, and replacing the code that does the timing. (I decided to strip out the UNIX timing code rather than

#ifdef it because it would have required a large number of #ifdef statements to modify it for Win32 usage.) The positive side of this is code that is much closer to ANSIit would be very easy to modify this code to compile and run in UNIX. On the negative side, the timing functions do not contain near the levels of granularity that was contained in the UNIX code (milliseconds rather than microseconds).
P O RT I N G I SS U E S A N D S O LU T I O N S

There were a number of issues involved in porting TTCP to the Windows environment. First and foremost were the issues surrounding differences between BSD sockets (the sockets used in the UNIX environment) and Windows sockets.
SOCKETS

Microsoft has implemented several functions specific to their operating systems. Two of these functions, WSAStartup() and WSACleanup(), must be called by any application using sockets. WSAStartup() initializes the Windows socket dynamic link library. An application calls WSACleanup() when it is finished using sockets. These functions were added to TTCP at the top and bottom of the main() function. TCP data transfer under Berkeley sockets is performed with the generalpurpose I/O functions read() and write(). In Windows Microsoft chose to implement two socket specific data transfer functions: recv() and send(). The reason is because of the way Windows sockets are implemented. The call to socket() under BSD returns an int which can, in many ways, be treated as a file handle. The same call in Windows returns a socket handle (data type SOCKET). This socket handle is not in any way compatible with the file system. The following table shows the similarity between the Windows functions and the BSD functions.
BSD function int write(socket_handle, buffer, count); int read(socket_handle, buffer, buffer_size); Windows function int send(socket_handle, buffer, count, flag); int recv(socket_handle, buffer, buffer_size, flag);

As you can see, the only major difference between the two is an extra, rarely used flag parameter at the end of the Windows calls. BSD sockets closes sockets with the close() function. Again, since Windows sockets are not implemented as file handles they have implemented a separate function closesocket() to perform this task.

TIMING

UNIX has a variety of timing functions available which provide clock counts all the way down to the microsecond. In contrast, Windows has but a few. Only one of these functions provide a resolution below one second: the clock() function. This is an ANSI compatible function which returns the number of milliseconds since the computer was turned on. All of the UNIX timing function calls were reworked to work with this single function. So while the timing routines are now ANSI compatible, they do not contain the level of accuracy that the original timing functions contain.
ERRATA

1. The rest of the porting issues were concerned with minor differences between the UNIX and Windows run-time libraries. The read() and write() calls used to read and write to STDIN and STDOUT were replaced with _read() and _write(), the Microsoft implementations of the same functions. Also bzero(), was replaced with the ANSI compatible function memset().
EXAMPLE RUNS

TTCPW is run exactly as TTCP with two exceptions: 1. The verbose option (-v) does not work in the Windows implementation. This is simply due to the lack of timing functions available under that operating system. TTCPW has a new option to display ATM packet performance data (-M).

2.

The figures below show TTCPW being run in various modes against another version of TTCP running on a UNIX machine. Examples are given for TCP (figure 1), UDP (figure 2) and interactive (figure 3). Figure Windows95: TCP A:\>ttcpw -t -s renoir.csc.ncsu.edu ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> renoir.csc.ncs u.edu ttcp-t: socket2: UDP Run Figure Windows95: ttcp-t: connect -b256 -n50 -u -M renoir.csc.ncsu.edu A:\>ttcpw -t -s ttcp-t: 16777216 bytes in 216.52 seconds = 75.67 KB/sec sockbufsize=256 udp -> buflen=8192, nbuf=50, align=16384/0, port=5001, +++ ttcp-t: 2048 I/O calls, msec/call = 108.26, calls/sec = 9.46 renoir.csc.ncsu.edu ttcp-t: socket UNIX:sndbuf ttcp-t: % ttcpatm3 -r -s ttcp-t: 409600 bytes in 0.65 seconds = 615.38 KB/sec +++ ttcp-r: Which is at least 8532.8 ATM cells or 5.57 Mbits/sec tcpadapter level ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 at ttcp-r: 56 I/O calls, msec/call = 11.89, calls/sec = 86.15 ttcp-t: socket ttcp-r: accept from 152.1.57.94 ttcp-t: ttcp-r: 16777216 bytes (2048 nbufs) in 252.30 real seconds = 64.94 KB/sec +++ UNIX: ttcp-r: Which is at least 351232.0 ATM cells or 0.59 Mbits/sec at adapter level % ttcpatm3 -r -s -u ttcp-r: 10346 I/O calls, msec/call align=16384/0, port=5001 udp buflen=8192, nbuf=2048, = 24.97, calls/sec = 41.01 ttcp-r: 0.1user 1.2sys 4:12real 0% 1i+7d 152maxrss 0+2pf 10214+0csw socket ttcp-r: 352256 bytes (2048 nbufs) in 0.67 real seconds = 510.50 KB/sec +++ ttcp-r: Which is at least 8533.3 ATM cells or 5.37 Mbits/sec at adapter level ttcp-r: 45 I/O calls, msec/call = 15.33, calls/sec = 66.78 ttcp-r: 0.0user 0.0sys 0:00real 0% 0i+0d 150maxrss 0+1pf 43+0csw 1:

Windows 95: A:\>ttcpw -t renoir.csc.ncsu.edu ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> renoir.csc.ncs u.edu ttcp-t: socket ttcp-t: connect Test message number one. Test message number two. Any other string. ++ ttcp-t: 3 I/O calls, msec/call = 6915.41, calls/sec = 0.15 ttcp-t: UNIX: % ttcpatm3 -r ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket ttcp-r: accept from 152.1.57.94 Test message number one. Test message number two. Any other string. ttcp-r: 68 bytes (2048 nbufs) in 20.31 real seconds = 0.00 KB/sec +++ ttcp-r: Which is at least 1708.1 ATM cells or 0.04 Mbits/sec at adapter level ttcp-r: 4 I/O calls, msec/call = 5199.97, calls/sec = 0.20 ttcp-r: 0.0user 0.0sys 0:20real 0% 0i+0d 150maxrss 0+1pf 4+0csw

Figure Interactive

3:

I N S TA L L AT I O N

TTCPW requires Windows NT/95 (or later) to run. It will not run under Windows 3.1 including Windows for WorkGroups. There are no special installation instructions. You may run the program from any disk or directory from a DOS window. It was tested using the Microsoft TCP/IP stack provided with Windows95. It has not been tested under NT or any other TCP/IP stack. Windows NT should not present any problem whatsoever. It should have no problems running with any version of WinSock complying with revision 1.1 or later. (The only reason I would shy away WinSocks of revision 1.0 is because many of them were unstable.)
C O M P I L AT I O N

TTCPW was compiled using Visual C++ version 4.0. To compile the program: 1. Copy the source files to a hard drive directory. This is necessary because Visual C++ will generate several large files during the process of the build which can total 1 megabyte or more. 2. 3. 4. 5. Start Visual C++. Select Open from the File menu. Open the file ttcpw.mdp. This is the project file for ttcpw. Select Build ttcpw.exe from the Build menu.

The program file ttcpw.exe will be located in the Release directory off of the directory the source files were located in.

APPENDIX A ORIGINAL TTCP DOCUMENTATION

NAME ttcp - test TCP and UDP performance

SYNOPSIS ttcp -t [-u] [-s] [-p port] [-l buflen] [-b size] [-n numbufs] [-A align] [-O offset] [-f format] [-D] [-v] host [<in] ttcp -r [-u] [-s] [-p port] [-l buflen] [-b size] [-A align] [-O offset] [-f format] [-B] [-T] [-v] [>out]

DESCRIPTION Ttcp times the transmission and reception of data between two systems using the UDP or TCP protocols. It differs from common ``blast'' tests, which tend to measure the remote inetd as much as the network performance, and which usually do not allow measurements at the remote end of a UDP transmission.

For testing, the transmitter should be started with -t and -s after the receiver has been started with -r and -s. Tests lasting at least tens of seconds should be used to obtain accurate measurements. Graphical presentations of throughput versus buffer size for buffers ranging from tens of bytes to several ``pages'' can illuminate bottlenecks.

Ttcp can also be used as a ``network pipe'' for moving directory hierarchies between systems when routing problems exist or when the use of other mechanisms is undesirable. For example, on the destination machine, use: ttcp -r -B | tar xvpf -

and on the source machine: tar cf - directory | ttcp -t dest_machine

Additional intermediate machines can be included by: ttcp -r | ttcp -t next_machine

OPTIONS

-t

Transmit mode.

-r

Receive mode.

-u

Use UDP instead of TCP.

-s

If transmitting, source a data pattern to network; if receiving, sink (discard) the data. Without the -s option, the default is to transmit data from stdin or print the received data to stdout.

-l length Length of buffers in bytes (default 8192). For UDP, this value is the number of data bytes in each packet. The system limits the maximum UDP packet length. This limit can be

changed with the -b option.

-b size Set size of socket buffer. The default varies from system to system. This parameter affects the maximum UDP packet length. It may not be possible to set this parameter on some systems (for example, 4.2BSD).

-n numbufs Number of source buffers transmitted (default 2048).

-p port Port number to send to or listen on (default 2000). On some systems, this port may be allocated to another network daemon.

-D

If transmitting using TCP, do not buffer data when sending (sets the TCP_NODELAY socket option). It may not be possible to set this parameter on some systems (for example, 4.2BSD).

-B

When receiving data, output only full blocks, using the block size specified by -l. This option is useful for programs, such as tar(1), that require complete blocks.

-A align Align the start of buffers to this modulus (default 16384).

-O offset Align the start of buffers to this offset (default 0). For example, ``-A8192 -O1'' causes buffers to start at the second byte of an 8192-byte page.

-f format Specify, using one of the following characters, the format of the throughput rates as kilobits/sec ('k'), kilobytes/sec ('K'), megabits/sec ('m'), megabytes/sec ('M'), gigabits/sec ('g'), or gigabytes/sec ('G'). The default is 'K'.

-T

``Touch'' the data as they are read in order to measure cache effects.

-v

Verbose: print more statistics.

-d

Debug: set the SO_DEBUG socket option.

SEE ALSO ping(1M), traceroute(1M), netsnoop(1M)

Bonner, Pat. Network Programming with Windows Sockets. Prentice-Hall, Inc., 1996. Microsoft, Win32 Programmers Guide, Microsoft Press, 1995.