| Direct
Web Service
Defining
Direct Web Service Mode
Advantages of Direct Web Service
Mode
Setting Web Crossing to Run in Direct Web Service
Mode
Other Settings
Troubleshooting
Resources
The Web Crossing
server can be run in conjunction with another web server, such
as Apache, WebSTAR or IIS. Web Crossing can also run by itself, without
the need for an external web server.
Defining
Direct Web Service Mode
When
Web Crossing runs by itself, without using an external web server, it
is referred to as Direct Web Service Mode, or Direct HTTP Mode.
Conceptually, your server setup looks as shown in figure 1. When
Web Crossing runs under another web server it is referred to as CGI
Mode.
Figure
1 - Direct Web Service Mode
When
running in Direct Web Service mode, Web Crossing communicates directly
with the users' browsers, without the necessity of communicating
through an external web server. Web Crossing serves from its own webx.db
database, which contains all the forums and user information,
and also can serve ordinary home pages directly from the html
directory, located in the Web Crossing server directory. Ordinary web
pages served through Web Crossing can contain WCTL,
providing dynamic content and access to the Web Crossing database for
ordinary web pages.
The
Advantages of Direct Web Service Mode
There
are many. They include:
- There
is no need to install or setup (or purchase!) a separate web
server.
- Since
there is no need to communicate through an external web server,
there is no "CGI bottleneck." In other words, you
are assured of the fastest possible communication between Web Crossing
and the accessing user's browser.
- If
you have users accessing from behind a firewall, and those users
wish to use Web Crossing Chat then Direct Web Service will also provide
chat through the standard Web Port 80, allowing them access.
(Most firewalls block other port numbers for their users.)
To
Set Your Web CrossingServer to Run in Direct Web Service Mode
Go to
Control Panel > Direct Web Service
and check the box labeled Enable direct Web (HTTP) service
from Web Crossing.
The default
web port number is port 80. If another web server is already running
on the same server machine it is likely that it, too, is using
port 80. You must be careful to insure that two servers on the
same machine, under the same IP address are not using the same
port number or neither server will operate correctly.
To run
Web Crossing and another web server on the same server machine, using
the same IP address, either Web Crossing or the other web server must
use a different port number, such as 8080.
Other
Direct Web Service Settings
| Web
Service Port |
In
this box you can specify an alternative port, for example:
8080
or
you can specify an IP address and port as in:
210.226.165.207:80
Web Crossing
supports multihoming on platforms that allow multiple IP
addresses, such as most Unix systems. This allows you to
run multiple Web Crossing servers in Direct Web Service Mode, all
using Port 80. This feature is also called IP Aliasing.
You
may also enter a list of IP-Address:Port pairs, separated
by blanks, commas or newlines. All listed address:port pairs
will be listened to by Web Crossing.
|
|
Maximum number of simultaneous requests |
You
can modify this number to help with your load balancing.
The default value is 64, which means that Web Crossing will handle
up to 64 simultaneous requests from browsers. Increasing
the number will increase the number of users handled simultaneously
at a busy site.
Beware!
If you make this number too large, you can actually cause
the serving time per request to increase, resulting in slow
serving. If your Internet connection is slow (for example,
56K ISDN) you may actually want to decrease this value in
order to handle requests more quickly. In other words, there
is always a trade off between bandwidth and the number of
requests you can handle effectively in a fixed period of
time.
|
|
Directory for data files |
This
is the "root" directory for serving ordinary web
pages. If you leave this entry blank, then your root directory
will be the same as your Web Crossing server directory. This
is not recommended.
One
common setting is:
./html
which
means that all your ordinary web pages are found in the
html directory inside your Web Crossing server directory.
You
can also specify absolute pathname in your file system.
For example:
/usr/home/webxpages
Note
that you must assure that the specified directory actually
exists in your file system.
In
the MacOS version you would specify
:/html
instead
of ./html (a colon is used to separate directories on the
Mac).
|
|
Web Crossing Script Name |
This
defines a "script name" that is used in building
Web Crossing URLs. If left blank the default script name is
Web Crossing
In
most cases there is typically no need to change this entry.
One reason you may want to change it is if you are porting
over a webx.db database from another system with
a different script name. Rather than change the contents
of the database, you can just change the script name here
to match up. For example, if you port a webx.db database
over from a Web Crossing server that had a script name
cgi-bin/webx
you
can change the script name here to correspond to that.
|
|
URL for top-level access |
When
users access your Web Crossing server you can specify the top-level
page they first see by the entry here.
For
example, to have users go directly to the top-level of the
discussion boards enter:
/webx
here
(which is the default).
To
have users go to the location specified by the unique
ID .ee6b61b you can enter:
/webx?.ee6b61b
If
your Web Crossing server is listening
to more than one port then you can also specify different
top-level access points for different ports. For example,
to have people accessing via port 80 go to the top level,
but have people accessing via port 81 go to the location
specified by the unique ID .ee6b61b, you can enter:
210.226.165.207:80=/webx
210.226.165.207:81=/webx?.ee6b61b
You
can specify any Web Crossing action
URL, having different people accessing via different
ports accessing not only different locations but also performing
different actions, such as running different customized
macros.
|
|
Common log filename |
If
you specify a filename here then an access log is maintained
in the Common Log file format. There are many third-party
analyzing tools that take Common Log files and produce statistics
about the use of your system.
If
you leave this item blank then no access log will be recorded.
This
feature is only available when running in Direct Web Service
mode. If you are running as a CGI then you must rely on
the external web server's log capabilities.
This
feature should not be confused with the Log File feature
in the Sysop Control Panel. That Log File feature is available
for both Direct Web Service mode and CGI mode and provides
basic logging of requests and the ability to perform detailed
TCP/IP logs for diagnostic purposes.
|
|
Include referrer and user agent in the common log output |
One
of the optional features of the Common Log format is the
ability to record the referrer (the URL from which the user
came) and the user agent (the type of browser that was used
for access. If this box is checked, both the referrer and
the user agent are recorded in the Common Log file.
The
referrer is particularly useful for analyzing where your
users are learning about your site. The user agent shows
computer platform (Windows, MacOS, etc.) in addition to
browser type, which is also helpful information when designing
your web forum pages.
|
|
Web service to FastCGI routing |
FastCGI
is, as the name implies, a fast alternative to ordinary
CGI. Almost the same speed as Direct Web Service is maintained.
Your Web Crossing server can act as a front end server to a set
of other servers capable of communicating via FastCGI.
The
most obvious use for this is if you have multiple Web Crossing/Platinum
servers running on a large site, mirroring a webx.db.
For load balancing purposes, you want to route incoming
users in a round-robin fashion among the different platinum
servers. Web Crossing can be used as a software round-robin
server.
The
Port for incoming HTTP requests specifies an ip-address:port
pair for receiving routing requests, such as:
1.2.3.4:80
If
your Web Crossing server is not performing routing to a FastCGI
server then you can leave this blank.
The
number of simultaneous HTTP connections specifies how many
incoming routing connections can be handled at the same
time.
The
Destination FastCGI Servers are are list of servers to which
requests are routed in a round-robin fashion, for example:
3.4.5.6:1118
3.4.5.7:1118
|
Troubleshooting
If network
errors occur
- Make
sure no other service is running under the same IP address and
port number combination.
- Make
sure your server is correctly connected to a network and that
the IP addresses are correct. Remember - you cannot just decide
IP addresses yourself. If you are part of the Internet, these
IP addresses are assigned to you.
Resources
Sysop
Documentation
Sysop
Control Panel
Web Crossing
FAQ
Recommended
Book
- DNS
and BIND, a book by Paul Albitz & Cricket Liu, O'Reilly
& Associates, 1992. Especially Chapters 1 - 4.
|
