Re: Web listener


Peter,

FYI, JD3 uses the connection pool redirection/reconnection method that I
mentioned earlier. When the request comes in from CGI the app connects to D3
on a master port phantom. The master port phantom then tells the CGI client
app to reconnect to D3 over port XXXX, which happens to be an existing
socket listening phantom. While a lot of developers have implemented APIs
using this method I don't like it from a portability or scalability
standpoint. Yes, it works, and there are sites out there using all kinds of
connectivity solutions to no ill effect. It is much better, IMO, to utilize
a standard I/O service to call the O/S program from a network socket. Of
course, the argument between those two is licenses. The first retains a
measurable amount of usability over a set license count while the latter is
first-come first-serve with no license retention. Of course, the latter
solution can be designed to include pooling too but the interconnecting web
you begin to weave can be more of a pain to manage than to construct. After
several months of tinkering and discussions with myself and others, I
settled on a hybrid socket/inetd/file spool method. Here's my thinking
behind it:

1) People are comfortable calling a TCP service from a CGI app. Direct
executions on the O/S, from the CGI app, can be a security issue. Also
running the web server on the MV server can be/is a security risk. It's best
to limit the contact between the web server and MV server by splitting them
and using firewalled sockets for communications.

2) Inetd, XInetd, Winetd, and even the standard I/O services inside Windows
were written specifically for the purpose of handling bulk socket
connections and bridging the remote ends with multiple instances of a single
program that talks over file handles 0 and 1. They do a great job at it and
are solid building blocks, else they would not be at the core of
Linux/Unix/etc.

3) MV has nice locking mechanisms. By using the built-in file locking mech
you can control file (O/S directory) and item (O/S file) level activity on
the incoming and outgoing part. Incoming is from CGI to MV while outgoing is
from MV to CGI. When the std I/O queue manager gets a request for a MV
resource from the CGI app it assigns a unique request ID and writes the
request to a pickup folder. The ID is then written as the name to a null
file in the "incoming bin". Each MV phantom does a READU on the "incoming
bin" and picks up one request to handle, deletes the file(MV item), and then
reads in the real request file to process. The same thing happens from MV in
reverse when the output is assembled and ready for pickup.

The spooler in #3, in conjunction with the MV file locking and O/S file
polling ability, is really what makes the solution flexible and run-time
adjustable. Phantoms can be added and removed at any point manually with no
ill effect. You could do this automatically by implementing a simple phantom
manager that provides and updates a PIB/status map that the service phantoms
can check and update periodically.

The disconnection between the service handler and the client bridge means
that you can also use the service from any point between the CGI app and the
MV service phantom. I call it local request injecting. You could write
external services that plug directly into the spooler and utilize the MV
services to obtain custom output that isn't even web page oriented. The CGI
part of MVWWW is just a simple socket client app that does I/O with the
spooler and the CGI environment. Get rid of it and you could call MVWWW
MVCONNECT since almost all of the code is in the spooler/MV service. Each
spooler instance is waiting for a specific response ID from MV so other
requests regardless of what they are, are ignored. A typical local injection
example is writing a request directly to the file pick-up bin directly from
MV, reading the response back into MV, and finally sending the web content
out through another medium.

I'll stop blabbering now and wasting space. If you want more info drop me
an e-mail or catch me on irc.freenode.net ##pick or irc.efnet.org #openqm.

GlenB


"Peter McMurray" <excalibur21@xxxxxxxxxxx> wrote in message
news:Wk21l.1827$cu.554@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi
This is incredible. I got Bryan down to take our web guys through this at
the time, unfortunately that was the business bit that went awry. I am
very pleased to see that it is still working and shall look deeper into
it, your write up is just what one needs to get an understanding of it.
Thanks
peter McMurray
<terrypen@xxxxxxxxxxxx> wrote in message
news:312656be-6f43-48fc-add1-d53139493984@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I've been using jd3 for several years with great success - go here:
http://www.djpatterson.com/jd3php.html and you'll see what it's about
- it works well for calling a subroutine from a php page and receiving
the return from the d3 server. All you need to do is code php to send
the name of the subroutine and its arguments to the d3 server located
at the address specified in the include file "d3.inc" (I think if
memory serves) and await the return of data from the server.

One of the apps I developed using this means is a dealer locator on
the client's web site. The web site is hosted "somewhere out there"
and the d3 server is inside the client firewall. Ports are mapped on
the firewall to send requests to the listening ports on the d3 server.
When a request is received, some code jumps into action, returns some
data and it displays on the user's browser. You should check it out.
Terry


On Dec 10, 2:43 pm, "Peter McMurray" <excalibu...@xxxxxxxxxxx> wrote:
Hi
A follow on to previous web threads. How does one catch the requests from
the web server. Please note I have not done this as I am still getting my
head around JavaScript, Dhtml, CSS etc.I knew PickBasic was great when I
swiched from Neat3 and Cobol. Nothing has changed.
My understanding is that one fires up several phantoms to listen and when
something comes down the line check the credentials, fire off the
requested
subroutine and return an answer.
I got the impression from Tony's video that one had to logon and off for
every request when using mv.Net. Obviously from his response I have this
wrong.
In the words of our woman in red "Please Explain"
Peter McMurray




.