没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
Waterloo TCP
Programmers Guide
Erick Engelke
Release 1.20
All Rights Reserved
Waterloo TCP Programmers Guide
page 3
Welcome to Waterloo TCP
Waterloo TCP is a TCP/IP stack which is freely available to anyone. There are no
royalties on the software. The only restrictions are that the kernal libraries may not be
sold by themselves and that the copyright of the authors is recognized.
A lot of work has gone into the library and the preparation of this documentation. The
cost of manuals and software needed to keep extending Waterloo TCP comes from
’donations’ cleverly disguised as purchases of this documentation.
Please note: this manual is copyrighted, you may not copy it without written permission by the
author. If you are interested in using this manual as part of a course, please contact me for a per
copy license fee for the manual.
If you have any requests or comments, please feel free to contact me by mail or E-mail.
If you would like to donate a program, especially in source, I would be pleased to add
it to our distribution with full acknowledgement.
Erick Engelke
Waterloo TCP Architect
Erick@development.watstar.uwaterloo.ca
If you didn’t know, MS-DOS a registered trademark of Microsoft and
UNIX is a registered trademark of Bell Laboratories.
Waterloo TCP Programmers Guide
page 4
How To Read This
This guide is written in a structured format, not an alphabetical list of functions, that list is in the
reference section. I was attempting to give some background before unleashing a disorganized
list of functions. I will occasionally mention "see ...", that is for later reference, bear with me
sequentially.
I am open to comments and suggestions for both the software and this manual. The first few
releases of the manual will tend to be wordy and some sections redundant. With your comments,
and more time to reflect, I hope to trim down and clarify the documentation.
Preliminaries
For any programs you write with Waterloo TCP, include TCP.H. It has all the necessary function
headers and macros. I will continue to distribute new TCP.H files with each new release of the
kernal, so you are recommended to not change this file for personal use.
The WTCP_VER flag will be incrementing, indicating things have changed. I will distribute
CHANGES.n (eg. CHANGES.105 when version 1.05 is released) to describe the effects.
I hate typing in unsigned this and unsigned that. The convention I have used here is byte, word,
and longword for the unsigned quantities.
During the design of the APIs, I eliminated every mechanism which would require more
memory. The result is a kernel and applications which consume less memory than most kernels
alone. That also meant a single stack, hence a single task, no callocs or mallocs in the kernal
(since some programs will be TSR’s) and efficiency over absolute cleanliness whenever possible.
That’s the way to do operating systems. The application programmers may do as they please, but
you are reminded that the APIs described here will give fast and small code. Do not feel that my
single task restricts you to a single task, the appendices give details on how to effectively use
multitaskers with Waterloo TCP.
When you program, you must use my language for this project, Turbo C. Everything is currently
small model. You cannot use register variables so set that in your make files or tcconfig.tc files right
now! For TCC users, set the -r- flag. For integrated environment users, select
Options/Compiler/Registers/Off.
Nutshell: How it works
The kernel is mostly a non-blocking system. It is also not tied to the timer tick for processing.
You must explicitly call it occasionally to do all the tcp/ip house keeping.
To make Waterloo TCP a little more friendly, I added macros and routines which make the kernel
look like a blocking, callable resource, basically like MS-DOS or UNIX. Since most programs end
up waiting on events like data arriving, the whole thing looks like a blocking system.
Waterloo TCP Programmers Guide
page 5
Important Concepts
Sockets
Waterloo TCP uses what I call sockets. Enough other people call other things sockets that I don’t
mind adding yet another confusing definition. For the rest of this manual, what I call sockets will
apply to my sockets, and not necessarily to any other programming environment.
A socket may be defined to be of type tcp_Socket or udp_Socket. You will have to use one of the
functions tcp_Open, udp_Open or tcp_Listen to open the socket, but subsequently any routine
of type sock... will work.
Note that I have made many functions non-blocking, this means you can do things between
functions. That provides power but may sacrifice simplicity, so I have added blocking macros
which make everything look a little more similar to UN*X or other systems. There are also
blocking functions available for you to use. See sock_... functions for more details.
An optional signal_handler may be passed during the open or listen functions. Please use NULL
until such time as this service is properly announced.
ASCII vs. BINARY
’C’ programmers are used to ASCII and binary oriented file i/o. To simplify some situations, I
have added a mode flag to the socket structure and several functions act upon it. If you intend
to use ASCII oriented instructions, call sock_mode with the socket in question and the flag
TCP_MODE_ASCII. You can return to binary mode at any time by calling sock_mode again
with the flag TCP_MODE_BINARY. Sockets always open in binary mode, so you must explicitly
indicate to use ASCII mode.
void sock_mode( void *s, word mode );
eg. if ( !tcp_open( s, 0, host, port, NULL )) return(0);
sock_mode( s, TCP_MODE_ASCII );
sock_wait_established( s, sock_delay, NULL, &status );
The mode flag affects sock_dataready and sock_wait_input because they normally respond as
soon as any data is available. In ASCII mode, these functions act as if no data is available until
a complete string is ready to be transferred. In ASCII mode, the operation of sock_puts changes
slightly as it appends a ’\n’ to the sent data, normally no ’\n’ is added. Remember, if you intend
to use sock_gets or sock_scanf, you must set ASCII mode.
No other functions are affected.
Kernel Initialization
The kernel must be initialized before it is used, likewise it must be shut down before your
application exits. Failure to shut down, for example, would cause you machine to hang the next
time a packet arrived for your application.
The easiest mechanism is to use sock_init(). It reads the configuration file, installs a control break
handler, sets up the automatic shutdown facility using atexit(), checks the packet driver, loads the
Ethernet address for ARP stuff, and clears tables. Note that sock_init removes the need for you
to call a routine before you exit if you use control break, exit(), or abort, retry, ignore. (the abort,
retry, ignore description is not correct at the date of publishing. Such an exit leave the system in an
unknown state)
剩余55页未读,继续阅读
资源评论
- 山风木风2011-12-27全面的英文资料,要是能有中文的就好了
- ac2012zy2012-02-29全英文的,看起来有点吃力,不过已经是很难得了。 文档版本是1.20.也不知道新旧程度
lxhyzu
- 粉丝: 1
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功