readme.txt

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

is loaded very heavy, you can either install another one and share the
load, or increase this timeout on the active servers, so that the client's
speed suffer, but server is giving away less network throughput to every
individual user thus being able of handling more users off the same pipe.

Suggested setting: depends on the number of users and pipe capacity.
Set to 0:1:2 when you need speed or to 3:6:9 when the server is overloaded.
0-4

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

HTTHost security filters configuration.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HTTHost implements a full control over a traffic by means of security
filters, which is an external plug-in DLLs. Filter has a range, that is
a set of IP addresses and/or ports to which it applies, when a client
requests tunneling to the specified addresses/ports.

Security filter logic:

1. Client requests tunneling to 'some.host:port'.
2. HTTHost resolves some.host into an IP.
3. HTTHost scans the list of the loaded filters starting at first.
4. The first filter that has a range that covers this IP:port, wins.
5. Filter can declare itself as being a connection filter only 
   (that is, it does not care for the data being transferred, both
   block and grant are of that kind), or a send and/or receive data
   filter. 
6. Every time HTTHost is about to do something that may be of a filter
   interest , like - connection attempt, data being sent or received,
   it calls the filter for confirmation or denial.
   
The SDK goes with two simple filters of the similar nature - block.dll
and grant.dll.

block.dll disallows the tunneling _to_ IPs and ports its ranges cover.
grant.dll allows the tunneling _to_ IPs and ports its ranges cover.

Security filters configuration is loaded once at startup from the
filters.cfg file, which should reside in HTTHost's directory.
It is suggested, yet not required, that the filters themselves also
reside in the same directory.

The general syntax for the file is:

filter=filter1.dll
range=baseIP,IPmask,basePort,Portmask
...
range=baseIP,IPmask,basePort,Portmask
filter=filter2.dll
range=baseIP,IPmask,basePort,Portmask
...
range=baseIP,IPmask,basePort,Portmask
....
filter=filterN.dll
range=baseIP,IPmask,basePort,Portmask
...
range=baseIP,IPmask,basePort,Portmask

Example 1: 

You want your clients to use HTTHost to open tunnels to server1:7777 and
server2:8888 only. Assuming server1's IP is 111.11.11.11, and 
server2's IP is 222.22.22.22, the following configuration will do the trick:

----------- filters.cfg, example 1 --------------

filter=grant.dll
range=111.11.11.11,0.0.0.0,7777,0
range=222.22.22.22,0.0.0.0,8888,0
filter=block.dll
range=0.0.0.0,255.255.255.255,0,65535

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

Example 2:

You want your clients to use HTTHost to open tunnels to any host
within C-class subnet of 123.45.67.* on ports above 1024 only.
You should make a copy of block.dll, let's say block2.dll.
This is a way you can duplicate filters entries in the cfg file.

----------- filters.cfg, example 2 --------------

filter=block.dll
range=123.45.67.0,0.0.0.255,0,1023
filter=grant.dll
range=123.45.67.0,0.0.0.255,0,65535
filter=block2.dll
range=0.0.0.0,255.255.255.255,0,65535

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

3. Monitor configuration.
~~~~~~~~~~~~~~~~~~~~~~~~~
HTTCentral is a monitoring utility for HTTHost(s).

It takes the list of HTTHosts from the file httcentral.lst, which 
has the following syntax:

host1:port1
host2:port2
...
hostn:portn

HTTCentral can be run from behind an HTTP proxy, in which case you should
specify the proxy parameters in the httcentral.ini file as follows:

ProxyHost=proxy.host.name
ProxyPort=proxy_port

You should allow your HTTHosts to be monitored from a certain IP address.
I suggest that this address is your company HTTP proxy address, so you 
can run HTTCentral on any PC from behind a proxy, since HTTHosts will 
see connections incoming from the proxy.

Short manual:

Refresh button cycles through the listed HTTHosts and retrieves the list
of parameters available for monitoring. Double clicking on a parameter name,
or on a parameter value itself cause the value of that parameter to be
retrieved.

The following parameters can be monitored:

allocated_memory - KBytes of memory allocate in internal HTTHost heap.
cpu_type - number and types of CPUs installed in the server.
external_connections - the current amount of open tunnels.
external_connections_total - total amount of server connections.
external_data_received - KBytes of data received from external sources.
external_data_sent - KBytes of data sent to external sources.
filters - number of security filters configured.
filter(i, name) - for each filter - the name of the DLL.
filter(i, range) - the range covered by that filter.
filter(i, signature) - the hash signature of the DLL.
physical_memory - KBytes of server's physical memory as reported by Windows.
running_time - time since HTTHost was started in hh:mm format.
version - string with HTTHost version.

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

4. Client configuration.
~~~~~~~~~~~~~~~~~~~~~~~~
Client for HTTHost in this SDK is any application that uses HTTPort.DLL.
Please see the following files for more information and samples:

DLL\Sample\test.c - sample client application.
DLL\Interface\HTTPortDLLDefs.pas - interface unit source code. Contains
detailed calling and errors explanation.

The following are the only things that worth to mentioned:

1. HTTPort has to deal with all kind of proxies, which means, even not
   fully HTTP compatible. This lack of compatibility may result from a poor
   proxy design, or just from a strict security measures.
   
2. HTTPort may be used in one of three modes:

CONN_MODE_CONNECT - uses HTTP CONNECT method for proxy bypass. Fastest and
preferred method but not always supported by proxy. This method does not
require HTTHost at all.

CONN_MODE_REMOTE - uses HTTP GET method for calling remote HTTHost.

CONN_MODE_AUTO - a mixture of two above and a good default value for the
first run. Attempts to use CONNECT and if it fails, switches to REMOTE.

3. When using CONN_USE_REMOTE, the data that HTTPort sends to HTTHost is
embedded in the HTTP request. The optimistic approach is to add a separate
request header field which contains an encoded data. This is a preferred
method, but some proxies remove the header fields they don't know the
meaning for (which is against the HTTP standard). In this case HTTPort can
be switched to alternative mode, when data to send is embedded into 
the URL itself. This makes the URL to grow and is also much slower when
sending but it works on those bad proxies. This is what DATA_OVERRIDE
option stands for. When you specify a non-zero value for DATA_OVERRIDE
option, it's exactly the number of raw bytes to be sent within an URL.
In case it is 0, data will be sent as a header field.

4. When client application is running the first time, you should make a
following defaults: connection mode is CONN_MODE_AUTO, DATA_OVERRIDE is 0.
Whenever the client application is shutting down, you should use 
H_GetProxyStats for retrieving the values for conection mode and data override
which have actually been used and store them as a client config.
Next time the client starts you should load the saved config values 
for that two options and set them, so the library will not have to guess
it again.

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

5. Copyright information.
~~~~~~~~~~~~~~~~~~~~~~~~~

This licensed version of HTTPort SDK may only be used in accordance with
the licence agreement. See license.txt for more information on licensing
this software.

HTTPort, HTTHost, HTTPort SDK are written by Dmitry Dvoinikov.
(c) 1999-2001 Dmitry Dvoinikov

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

End of readme file