Introduction
Welcome to DXSock 3.0 documentation volume 1. This book aims to help you get ready
to start developing Internet or intranet servers with the latest version of the DXSock suite. In this
introduction, we introduce socket technology in general and talk about prerequisite design goals
that can help you prepare for developing Internet or intranet servers.
These books help you understand and appreciate the subjects and materials you need to
develop servers. The books are aimed strictly at software engineers. They do not teach you
programming or how to implement individual protocols. Instead, we (the authors) present and
dissect the questions and problems that you’re likely to encounter developing servers. We share
with you how you can resolve these questions and problems lie using the DXSock suite as your
ally.
We start by addressing the foundation –- discussing the basic concepts of what is the
sockets, and what is the client server model. This prepares you for the primary subject of this
book the DXSock Winsock Application Programming Interface (DXSock Winsock API).
Introduction – Sockets
1
Basic concepts
The basic building block for TCP/IP and UDP/IP communications is the socket, to which a
name may be bound. Each socket in use has a type and an associated process.
Sockets are typed according to the communication properties visible to a user.
Applications are presumed to communicate only between sockets of the same type, although
there is nothing that prevents communication between sockets of different types should the
underlying communication protocols support this.
Two types of sockets currently are available to a user. A stream socket provides for the
bi-directional, reliable, sequenced, and unduplicated flow of data without record boundaries. And
the other is a datagram socket, which supports bi-directional flow of data, which is not promised
to be sequenced, reliable, or unduplicated. That is, a process receiving messages on a datagram
socket may find messages duplicated, and, possibly, in an order different from the order in which
it was sent. An important characteristic of a datagram socket is that record boundaries in data
are preserved.
Client-server model
The most commonly used paradigm in constructing distributed applications is the
client/server model. In this scheme client applications request services from a server application.
This implies an asymmetry in establishing communication between the client and server.
The client and server require a well-known set of conventions before service may be
rendered (and accepted). This set of conventions comprises a protocol that must be
implemented at both ends of a connection. Depending on the situation, the protocol may be
symmetric or asymmetric. In a symmetric protocol, either side may play the master or slave
roles. In an asymmetric protocol, one side is recognized as the master, with the other as the
slave. An example of a symmetric protocol is the TELNET protocol used in the Internet for
remote terminal emulation. An example of an asymmetric protocol is the Internet file transfer
protocol, FTP. No matter whether the specific protocol used in obtaining a service is symmetric
or asymmetric, when accessing a service there is a "client process'' and a "server process''.
A server application normally listens at a well-known address for requests. That is, the
server process remains dormant until a connection is requested by a client's connection to the
server's address. At such a time the server process "wakes up'' and services the client,
performing whatever appropriate actions the client requests of it. While connection-based
services are the norm, some services are based on the use of datagram sockets.
评论11
最新资源