readme.txt

HTTP 2 SOCKET的完整开发包 HTTP 2 SOCKET的完整开发包.rar

This is a readme file for a licensed version of HTTPort SDK.

It's included with DEMO version so that you see what's in full package.

--------------------------------------------------------------------------------

Table of contents.
~~~~~~~~~~~~~~~~~~
1. SDK components overview.
2. HTTHost configuration.
3. Monitor configuration.
4. Client configuration.
5. Copyright information.

--------------------------------------------------------------------------------

1. SDK components overview.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
This SDK includes the following components:

a) HTTHost - generic TCP/IP through HTTP tunneling server. Accepts HTTP
   requests from the clients, in case of SDK - applications using httport.dll,
   and translates the requests into local TCP/IP actions. Multiple instances
   of HTTHost can run on a single PC provided that their listening ports
   do not conflict. Multiple HTTHosts can be used by a single client,
   provided that the client knows the locations of all the hosts it wishes
   to use.

   This SDK includes both GUI and console versions of HTTHost. Console
   version may be run as service using srvany or similar program.

b) Block.dll and grant.dll - security filters for HTTHost. Used for fine
   tuning tunneling restrictions with HTTHost.
   
c) HTTCentral - HTTHost monitor. Allows remote monitoring of HTTHosts.

d) HTTPort.dll - application level dynamic link library for interfacing with 
   HTTHost.
   
e) Source code for the library. Includes implementation of the interface unit
   only. Interface header files for C and Delphi.

f) Test application in C which demonstrates the principles of the DLL usage.
   Compiled executable for this application.

g) Registry tweaking file you are suggested to import into registry on the
   HTTHost servers. Optimizes TCP/IP settings for the needs of HTTHost.

--------------------------------------------------------------------------------

2. HTTHost configuration.
~~~~~~~~~~~~~~~~~~~~~~~~~
HTTHost is a single Win32 executable file. No libraries, or components
are required to run it. Minimum system requirements include Windows NT/2000
with TCP/IP installed.

The hardware configuration depends in fact on the number of clients that
are using it. The simplest way to calculate the memory requirements is to 
multiply the number of simultaneous users by 64K. This is a very rough
estimation, but it gives you the idea. That is for 1000 _simultaneous_
users you need about 64M physical memory for HTTHost itself. Nevertheless,
that number of users requires really fast CPU, which is probably dual
Pentium III something or similar.

--------------------------

HTTHost reads its configuration upon start from the htthost.ini file,
which must reside in the same directory. This file includes the following
parameters:

NOTE: All of the options can be configured at runtime from the Options
tab, and this is the preferred way to configure HTTHost. Changes take
place when you click Apply button.

--------------------------

BindIP=X.X.X.X
Interface: Options -> Bind to IP

Binds HTTHost to accept incoming HTTP requests on specified IP/interface
address only. 0.0.0.0 here means binding to all available interfaces.
Dotted IP (0 <= X <= 255).

--------------------------

ListenPort=X
Interface: Options -> Bind to IP -> Port

Sets HTTHost to listen the specified port on the above interface.
Port number (0 <= X <= 65535).

--------------------------

CentralIP=X.X.X.X
Interface: Options -> Central IP

The IP address to accept monitoring requests from. HTTHost will not allow
to monitor its state using HTTCentral, if the request originates from IP
different than that. 0.0.0.0 here means - allow monitoring for everybody.
Dotted IP (0 <= X <= 255).

--------------------------

PortShared=1 OR 0
Interface: Options -> Passthrough

Allow or disallow passthrough cloaking feature of HTTHost (AKA port sharing).
If enabled, HTTHost will pass all the requests it cannot recognize to the
specified address, which is presumable some other HTTP server.
This means that if anyone decides to surf (point one's browser) to the host
where HTTHost resides, he or she will get the exact copy of the shared site.
This setting is recommended to be turned on, yet it does not interfere
HTTHost tunneling performance.
1 or 0.

--------------------------

SharedAddress=host.name.com OR X.X.X.X
Interface: Options -> Passthrough -> Host name or IP

Host name (resolvable from HTTHost's point) or dotted IP of the HTTP server
to pass the requests through if passthrough is enabled.
In case it's set to nothing (or, to unresolvable name), HTTHost will
automatically set this to 127.0.0.1.
Host domain name or dotted IP (0 <= X <= 255).

--------------------------

SharedPort=X
Interface: Options -> Passthrough -> Port

HTTP server port to pass the requests to if passthrough is enabled.
Port number (0 <= X <= 65535).

--------------------------

HeaderField=Some_string
Interface: Options -> Passthrough -> Original IP header field

Specifies the additional HTTP header field that HTTHost will append to 
the request it passes through. This allows the remote site to perform
appropriate logging, if it's aware of HTTHost, of course. Otherwise,
all connections are seen by the remote HTTP server as incoming from
HTTHost machine with no indication where the request really came from.
This field can be empty, in which case the request header field will be
omitted.
Character string. Recommended that you set it to X-Whatever, as proposed
in RFCs.

--------------------------

Passthrough example:

If HTTHost is set to pass requests through to www.somesite.com on port 80
with header field of X-Original-IP, and it receives the following request
from 207.251.25.63:

GET robots.txt HTTP/1.0
Host: htthost.server.com

The request that will actually be passed to the somesite HTTP server is:

GET robots.txt HTTP/1.0
Host: www.somesite.com
X-Original-IP: 207.251.25.63

End of Example.

--------------------------

MaxLocalStorageBuffer=0..7
Interface: Options -> Max. local buffer

This is actually an index in the drop down list. The option itself
specifies the maximium amount of data to be buffered locally for a single
connection. Example - the client has requested tunneling for some external
HTTP proxy. The client has sent a request to GET a huge file.
The proxy is transferring data to HTTHost. HTTHost will not receive more 
than that amount of data before the client fetches its data thus freeing
some HTTHost memory. That is - proxy to HTTHost data transfer is delayed
until the client receives the data which is already receieved by HTTHost.
There is no suggested value for that parameter.
0 to 7.

--------------------------

Timeouts=0..4
Interface: Options -> Timeouts

This is actually an index in the drop down list.The option itself
is three comma-separated timeout values in seconds. The description
below is simplified a little, so that it's easier to understand.

This is how it works - HTTPort communicates with HTTHost by means of
series of GET requests, issuing a proper timeout before every request.
The decision on how long the client has to wait before sending next request
is made by server. Depending on the tunneled connection state HTTHost 
instructs it's clients to wait one of these three timeouts. If the
tunneled connection is active, the first timeout is set, if it's idle
for a little time, second, and if it's idle for a long time, third.
This makes possible to put the idle connections to "lower priority", so that
they do not load the server. From HTTHost admin's point of view, this
setting is the tradeoff between client speed and server load. If the server