dos环境下WATTCP网络编程指南

5星 · 超过95%的资源需积分: 20 54 浏览量更新于2024-08-02 收藏 404KB PDF 举报

WATTCP网络编程库是Erick Engelke编写的文档，专为DOS环境下的TCP/IP编程提供详细的指导。这份文档包含了丰富的内容，从入门到高级技术，旨在帮助开发者理解和掌握在缺乏现代操作系统支持的环境下进行网络通信。 **章节概览：** 1. **Getting Started** (第4页) - 介绍了如何开始使用WATTCP，可能包括环境设置和基本概念的回顾，确保读者对后续内容有基础的理解。 2. **Programming Preliminaries** (第4页) - 提供了编程前的基础知识，如硬件需求和TCP/IP配置，这部分强调了在DOS系统中的特殊性。 3. **Hardware Requirements** (第4页) - 对于DOS系统，可能涉及到必要的硬件配置，例如串口或并行端口的使用，以及可能存在的兼容性问题。 4. **TCP/IP Configuration** (第4页) - 指导如何在DOS环境中正确配置TCP/IP协议栈，确保程序能与网络通信。 5. **Introduction to Network Programming** (第4页) - 解释了网络编程的基本原理，以及如何通过套接字API在DOS系统中创建和管理连接。 6. **Sockets** (第4页) - 对DOS下套接字的工作原理进行了详细阐述，包括阻塞和非阻塞模式的选择，以及它们在客户端-服务器模型中的应用。 7. **To Block or Not to Block** (第5页) - 探讨了在资源受限的DOS环境下，何时选择阻塞和非阻塞I/O模式以优化性能。 8. **Clients, Servers, and an Initial Example** (第6页) - 通过一个简化的示例展示了如何编写基本的客户端和服务器程序，以便读者理解实际操作。 9. **More Details** (第10页起) - 进一步讲解了诸如ASCII vs. BINARY、内核初始化、套接字函数等主题，帮助读者深入了解细节。 10. **Advanced Topics** (第10-29页) - 包括网络数据类型转换（如htons, htonl等）、IP地址解析（inet_addr, inet_ntoa）以及超时处理（ip_timer_init, ip_timer_expired）等。 11. **Utilities** (第30-32页) - 描述了实用工具如_ping_和_psocket_的功能，用于测试和展示远程主机信息。 12. **Configuration Files** (第21页) - 谈论了配置文件的使用，可能是设置参数或保存连接信息的地方。 13. **Help for UNIX Programmers** (第22页) - 针对那些熟悉Unix网络编程的读者，提供了向DOS环境迁移的指导。 14. **Technical Reference** (第24-29页) - 完整的技术参考部分，列出了详细的函数原型和使用说明。 15. **Conclusion** (未提及，但可能在文档末尾) - 总结了WATTCP的主要优点和在特定环境下的优势，以及对后续开发者的建议。 WATTCP文档是DOS时代网络编程的一份珍贵资源，尽管时代已变迁，但这份文档提供的技术原理和方法对于理解早期网络通信的底层工作原理仍有很高的价值。

TCP Programmers Guide

page 13

The basic socket writing function is sock_write. I have provided two additional functions which flush data

buffers and instruct the remote computer to pass the data to the user. sock_flush ensures the data already

written is transferred, and sock_flushnext affects the next data to be written. sock_flushnext is preferred

because it is much more efficient.

int sock_write( void * s, byte *data, int len );

int sock_fastwrite( void * s, byte *data, int len );

void sock_flush( void * s );

void sock_flushnext( void * s );

sock_puts will put a null terminated string. It performs an intrinsic flush (sock_flushnext). If in binary

(default) mode, the string is not changed, but if ASCII mode has been set with sock_mode, the string and a

subsequent \n are written. In either case, length of the original string is returned.

int sock_puts( void *s, char *text );

sock_putc places a character on the queue. If the character is a CR or LF, the stream is intrinsically

flushed. There is no character expansion performed. The character written is returned.

int sock_putc( void *s, char ch );

sock_printf writes the formatted string using sprintf and sock_puts and returns length.

sock_printf( void *s, char *format, ... );

Buffer Information

While the input and output buffers are not truly available to you, there are several routines which allow you

to inspect the size of the buffers (sock_tbsize, sock_rbsize), the number of bytes currently used in the buffer

(sock_tbused, sock_rbused), and the number of bytes not used (sock_tbleft, sock_rbleft). All values are <

32767 and in bytes. sock_t... functions refer to transmit buffers, while sock_r... functions refer to receive

buffers. udp sockets will return 0 for all transmit buffer functions since they do not maintain a transmit

buffer. Closed sockets should return 0 for all such functions.

int sock_tbsize( void *socket );

int sock_tbused( void *socket );

int sock_tbleft( void *socket );

int sock_rbsize( void *socket );

int sock_rbused( void *socket );

int sock_rbleft( void *socket );

Kernel Waiting

User applications may do polling to wait for data, but unless you are expecting real-time data (keystrokes)

or handling multiple sessions, you will want to have simple mechanisms to do your busy-waiting.

There are a few macros/functions to perform this task for most simple situations, they are macros called

sock_wait_... These macros have several things in common, they accept a timeout value for the current

operation and they routinely give the kernel a time slice, do a user defined yield if sock_yield was used,

check the keyboard for ^C (remember we safely close sessions), and call an optional short user defined

function repeatedly. They also accept a status pointer and handle errors so your input and output routines

do not have to.

sock_wait_established is used after an open to wait until the connection is complete. For udp connections

it returns immediately. sock_wait_input waits until some input arrives. sock_wait_closed is used after a

sock_close operations, but is unnecessary after a sock_abort. sock_tick just performs a kernel slice, but

replicates the error handling of the other sock_... functions.

TCP Programmers Guide

page 14

sock_wait_established( void * s, word seconds, word (*optional_fn), word *optional_status_ptr );

sock_wait_input( void * s, word seconds, word (*optional_fn), word *optional_status_ptr );

sock_wait_closed( void * s, word seconds, word (*optional_fn), word *optional_status_ptr );

sock_tick( void * s, word seconds, word (*optional_fn), word *optional_status_ptr );

Although not considered pretty, (what systems programming is?) the sock_... functions branch on an error

by setting *optional_status_ptr if it is non-NULL and doing a goto sock_err; The result is much simpler

user code. Performing the same with breaks and returns creates much larger modules. Using upcalls

looses context sensitivity. Obviously the other two mentioned options exist, they are simply computer

science imposed cleanliness. If you don't agree, look at the assembler code your compiler creates on a do

while loop.

Name Server

The name server allows users to specify names rather than dotted ip address. Usually you will just need to

use resolve and it will correctly handle names or dotted ip address formats.

longword resolve( char * host_string );

To save exe size, you may insist on dotted ip format only. Use inet_addr which returns an ip number in

longword format, or 0 on error:

longword inet_addr( char *dotted_ip_string );

The kernel uses the following constants which are automatically filled in by sock_init. You may read

def_nameserver and def2_nameserver, but writing to them is forbidden, particularly once the TSR version

is released.

extern char *def_domain;

extern longword def_nameserver, def2_nameserver;

What You Have Learned

You have learned almost everything which you will need in order to program TCP/IP applications using

WATTCPTCP. The remaining functions provide additional features, but are not really as important. You

might like to look at some of the sample applications in the reference section or in the software distribution

and see how they work.

When you are resonably familiar with their basic layout, return to this section for a brief description of the

rest of WATTCPTCP.

Nagle Algorithm

The performance and bandwidth costs of TCP can often be improved by using a simple and interesting

algorithm commonly referred to as the Nagle Algorithm.

The Nagle algorithm instructs us to not launch many small packets, but to store up new data until it can

piggyback an acknowledgement, or it reaches a maximum size, or the previous ack timed out.

For slow lines, Nagle reduces the number of headers transmitted which in turn reduces the ratio of

headerbytes

databytes

, which improves channel efficiency and will free up the channel for other uses. Without

Nagle, Telnet keystrokes invoke a flurry of small, wasteful packets. With Nagle, characters seem to 'bunch

up', but the actual performance is identical.

To assume that Nagle is only helpful over slow media is actually quite incorrect. TCP can be costly over

any network media, even Ethernet or FDDI where bandwidth may not be a problem. Consider the cost of

having your UNIX box receive many small packets from user TELNET sessions. If twenty secretaries are

TCP Programmers Guide

page 15

typing, say each at 80 words per minute. Those 133 packets per second are a nusance because they use up

your limited ethernet buffers as well as lots of processing time for interrupts, acknowledgements, tcp

protocol updates, etc. Over a local Ethernet, Nagle only has an influence when response times are slow,

namely when the network is congested or the server is very busy. Clearly those are exactly the times we

wish to reduce redundant packets, so Nagle is again appreciated.

These two scenarios explain why Nagle is on by default, but WATTCPTCP allows you to disable it with a

call. Some applications, such as X-Windows and real time data collection need responsiveness enough to

warrent being traffic hogs. Neither application is suggested to be used over anything but local subnets if

that gives you any idea of the importance.

sock_mode( void * socket, const flag );

eg. sock_mode( s, TCP_M ODE_NAGLE );

sock_mode( s, TCP_M ODE_NONAGLE );

You can turn it on or off as often as you like, thereby allowing you to gain the benefits of Nagle, while

temporarily disabling it to permit truely urgent data to be handled immediately.

Note: The Nagle algorithm has no effect on UDP sockets.

UDP Checksums

udp does not necessarily require checksums. According to the specifications, udp checksums should be

enabled by default. Many systems will only support udp checksums on for all connections or off for all

connections. WATTCPTCP defaults to checksums but allows you to override that decision on a socket by

socket basis.

Incomming data is always checked if the remote computer uses checksums. Disabling local checksums

speeds up both local and remote processing of datagrams.

A good reason to disable checksums is if your program implements its own checksum or you know that the

protocol is being run over networks which implement checksums or cyclic redundancy checks. Remember,

if the remote computer is on a different subnet, data may be passing through networks with no implicit

checksum or other error detection.

sock_mode( void * socket, con st flag );

eg. sock_mode( s, UDP_MODE_CHK );

sock_mode( s, UDP_MODE_NOCHK );

You can turn checksums on or off as often as you like, thereby allowing you to gain the benefits of

checksums for reliable data while gaining speed over unimportant data.

Note: The checksum flag has no effect on TCP sockets.

UDP Record Services

As discussed earlier, WATTCPTCP can work with udp connections just as easily as tcp connections, in fact

they both seem to act identically. Of course this appearance is actually quite fictitious. The basic sock read

functions (sock_read, sock_fastread, etc.) are not adequate for all your udp needs. The most basic

limitation in their is inability to treat udp as a record service.

TCP Programmers Guide

page 16

By record service I mean you will receive distinct datagrams which should be kept and distinct. You will

wish to know the length of the received datagram and the sender (if you opened in broadcast mode). You

may also receive the datagrams very quickly, so you must have a mechanism to buffer them.

Rather than add clumsy appendages to the standard socket reading functions to handle these new

requirement, I elected to add new functions specifically for record service.

Once a socket has been openned with udp_open, you can use sock_recv_init to initialize that socket for

the following functions. Note that sock_recv and related functions are incompatible with sock_read,

sock_fastread, sock_gets, sock_getc and sock_scanf. Once you have used sock_recv_init, you can no

longer use the older style calls.

sock_recv_init installs a large buffer area which gets segmented into smaller buffers. Whenever a udp

datagram arrives, WATTCPTCP stuffs that datagram into one of these new buffers. The new functions

scan those buffers. You must select the size of the buffer you submit to sock_recv_init, you should make it

as large as possible, say 4, 8 or 16 Kbytes. sock_recv_init returns 0 on success.

sock_recv scans the buffers for any datagram received by that socket. If there is a datagram, the length is

returned and the user buffer is filled. If no datagrams were found, sock_recv returns 0.

sock_recv_from works identically to sock_recv with the addition that it places the source ip address in a

user location pointed to by fromptr. This allows you to write a server using udp. To reply, you must open a

udp socket with the udp_open function. There is no facility in WATTCPTCP to simply send udp

datagrams without a socket.

int sock_recv_init(void *socket,byte *buffer,int bufferlen);

int sock_recv( void *socket, byte *buffer, int maxlength , int flags );

int sock_recv_from( void *socket, byte *buffer, int maxlength, longword* fromptr);

#include <stdio.h>

#include <tcp.h>

#define SAMPLE 401

udp_Socket data;

char bigbuf[ 8192 ];

main(int argc, char *argv[])

{

word templen;

char spare[ 1500 ];

sock_init();

if ( !udp_open( &data, SAMPLE, 0xffffffff, SAMPLE, NULL) ) {

puts("Could not open broadcast socket");

exit( 3 );

}

/* set large buffer mode */

if ( sock_recv_init( &data, bigbuf, sizeof( bigbuf ))) {

puts("Could not enable large buffers");

exit( 3 );

剩余79页未读，继续阅读

chnht

粉丝: 0
资源: 1

dos环境下WATTCP网络编程指南

DOS下的TCPIP开发包TCPIPDOSDEV

DOS TCPIP库

TCPIP编程

TCPIP编程例子

TCPIP编程教案

TCPIP 编程基础

EVC tcpip 编程范例

tcpip实例.rar_TCP/IP_TCP/IP编程_TCPIP delphi_tcpip 编程_服务器

TCPIP编程+实验一 URL基础编程 doc

高级TCPIP编程4.rar

最新资源