>[log in to unmask] (Eric Schubert ) wrote:
>> [snipped...]
>Eric, I have been toying with this very issue, that is
>"stateful" vis "state-less" client/server. I see the benefit
>when you are transferring things like what gopher and web
>servers typically do, but what about when you get into
>production databases? My experience says that you pay a lot of
>overhead for user validation and then database
>opens/initialization.
I hope some MPE lab folks are reading and can comment, because this
information to me is obsolete. My experience has been that fopens and Image
data base opens (NOT the first dbopen!) are very quick. I noticed the
change about the time MPE command language was supported MPE/iX 2.2ish?
I don't know, but I'd say some real big (and silent) performance
improvements were made in the file open area...or somewhere!
>How do you folks overcome this? I guess I
>could have server processes already running that have the db's
>opened and such, but I just curious what you found in this
>regard.
>-- Duane Percox (Quintessential School Systems)
> [log in to unmask]
Not advocating a large update system - but read only and casual update
can't be beat.
Generally, the server must ask for authentication, typically at the first
transaction, then return a ticket to the client. Afterward, with
state-less, the client must present the ticket to the server for the next
request. The server must cache tickets and index them to users.
We created a system that uses Telnet to authenticate users from AFS then
obtain a ticket from the HP gopher server. The user enters a small part of
the ticket into a gopher client searchable menu item (pointing to a gopher
server on the HP). The ticket is good for one time - to get a gopher root
menu. Afterward, a new large monster string called IndexToUser is generated.
If you know gopher protocol, there is a field that stores selections on the
client called a "selector string". However, we pull a trick. All returned
gopher menu selections from our HP server contain an IndexToUser embedded in
the gopher menu "selector" strings. Thus, any gopher request coming into
our HP has an Index that can identify who the person is and thus we can
build a custom report for them - student schedule, grades, rank in class,
charges at the bookstore, etc.
The Web:
Now, if you follow HTTP protocol, secure links are authenticated for
_each_ access to the link. The Web client typically prompts one time for user
name and password, caches it (in the client) and sends it to httpd server when
challenged by the server.
A basic form of encryption is used to encode passwords unless your client is
requested otherwise by httpd to perform RSA, for example.
We modified our Unix WWW NCSA 1.3 authentication source code to call AFS
authentication routines, now anyone on campus with an AFS account can obtain
custom secure Web links (~15,000). Our plans are to proxy into the HP Web
server after authenticated on the Unix / AFS server, passing environment
info (the user of course!) to the HP web server. Later, we plan a swap of a
secure Web server to proxy into the HP, giving us encrypted data end - to
-end, except between the Unix proxy and HP. However, between HP and Unix is
a secure physical subnet, so no encryption necessary.
All public Web clients can now do authentication, even NCSA Mosaic clients
(get a new version if yours doesn't) but end to end encryption is going to
be a commercial server. I don't know, Microsoft just obtained Mosaic! We
could have commercial Web (secure) clients everywhere in a year!
If you want super detail info on gopher, read my article in Sept'94 interact.
If you want to try secure links on an HP3000 running NCSA 1.3 WWW server, go:
http://jazz.external.hp.com
They are really cool! and on a 3000 too!
Hope this helps,
--------------------------------------------------------------------
Eric J. Schubert Administrative Information Services
Senior Data Base Analyst University of Notre Dame, IN USA
|
