The SocketTools Library Edition provides a comprehensive
collection of over eight hundred functions for performing a variety
of Internet related programming tasks. Although the size of the
SocketTools API may appear daunting, once you begin using the
libraries in your own applications you'll find that the various
libraries are designed to work together in a cohesive fashion.
After you've familiarized yourself with one library, the others
will become much simpler to use.
Throughout the Developer's Guide there are some general concepts
and terminology used that are essential to understanding how
SocketTools works. Each of these concepts is explored in detail,
however a general, broad overview can also be useful when you are
just getting started.
Protocols
A protocol, in terms of how the word is used in SocketTools,
refers to the rules for how programs communicate with one another
over a network. There are low level networking protocols such as
TCP and UDP, as well as high level application protocols like FTP
and HTTP. It can be helpful to think of a protocol as a sort of
language; for two programs to communicate with each other, they
must agree upon a protocol and understand how it is
implemented.
Connections
The process of establishing a connection enables one program to
communicate with another. Connection requests are made by client
applications, and accepted by server applications. When the server
accepts the connection request, the connection is completed. When
you use the Connect function to successfully establish a connection
to a server, a client session is created. SocketTools uses handles
to reference specific sessions, and an application can create
multiple client/server sessions if necessary.
Sessions
A session refers to an active connection between a client and
server program. This term is typically used interchangeably with
connection; however in some cases a single session may involve
multiple network connections. For example, the File Transfer
Protocol library establishes one connection, called the command
channel, when the client initially connects to the server. However,
when a file is being uploaded or downloaded, a second connection
called the data channel is created just for that transfer. When the
transfer completes, the second connection is terminated while the
original command channel connection remains active. Even though
there are multiple connections being made, SocketTools considers it
to be a single client session. An active session is referenced by
the handle which the Connect function returns to your program. When
the session is no longer needed, the library's Disconnect function
will terminate the connection to the server and release the
resources allocated for that session. After that point, the handle
is no longer valid and cannot be used in subsequent function
calls.
Authentication
Many servers require that clients authenticate themselves by
providing user names and passwords. Different application protocols
implement several different types of authentication, and some
protocols may support more than one authentication method. The
SocketTools API provides one of two general types of authentication
functions, depending on the protocol. For protocols which require
the client to authenticate itself, the libraries will provide a
Login function. Examples of this are FtpLogin, ImapLogin and
RshLogin. For protocols where authentication is optional, the
libraries will provide an Authenticate function. Examples of this
are HttpAuthenticate, NntpAuthenticate and SmtpAuthenticate. Refer
to the technical reference for the specific protocol to determine
if authentication is required.
Events
Developers who use visual programming languages like Visual
Basic will find the concept of events and event handling to be very
familiar. In general terms, the SocketTools documentation uses
"event" to refer to a mechanism where the library notifies the
client that an operation has completed, some action has taken place
or a change in status has occurred. SocketTools implements events
by posting user-defined messages to the application and/or invoking
callback functions that have been registered by the client. Events
can be handled by the client either by processing the messages in
the application's message queue, or by implementing callback
functions and registering those functions with the library. One
example of an event is a connection event, which is generated
whenever an asynchronous network connection is completed by the
client. Another example is a progress event, which is generated
periodically by the library to inform the client of its progress as
it sends or receives data. To determine what events are available
in a specific library, refer to the documentation for its
RegisterEvent function. More specific information about event
handling is provided later in this guide.