Re: General question on charging for data access
From: Gordon Burditt (gordonb.iv3ps_at_burditt.org)
Date: 12/16/04
- Next message: Fidelita Munos: "Timestamp from a Third Party"
- Previous message: jblanch: "Re: General question on charging for data access"
- In reply to: Frnak McKenney: "General question on charging for data access"
- Next in thread: Frnak McKenney: "Re: General question on charging for data access"
- Reply: Frnak McKenney: "Re: General question on charging for data access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 16 Dec 2004 05:21:20 GMT
>by being disconnected). Connection time was easy to measure, and it
>made sense to both the customer and the service provider as a rough
>metric for value received by a customer.
Connection time no longer provides a good metric (if it ever did),
as it used to be limited mostly by bandwidth, and now it is not.
>Things have changed. The stateless design of HTTP makes this kind
>of simple "time = value" approach to charging for services much more
>difficult to implement, since there seems to be no way of easily
>defining a "session" in its older sense. The term "session ID" used
>by PHP and other HTTP support environments is somewhat misleading,
>since, while it has a distinct beginning where authorization can be
>tested, there is no event corresponding to a "session ending".
Consider this possibility: a HTTP transaction *IS* a session. (Not
in the PHP sense.) Charge for them, or at least some of them, like
submitting an order or getting query results. Time is not a good
metric here (the slower your server is, the WORSE service the user
got). Consider a charge per query or a charge per unit of data.
>This is good for some purposes, As long as the HTTP server retains
>its copy of session information (perhaps days or weeks) a browser
>with the correct session ID can pick up a partially-completed user
>transaction (e.g. a book order from Amazon.com) from where it left
>off several hours previous. In fact, for better or worse, a
>different browser on a different system in a different location can
>pick up the same partially-completed user transaction.
A well-designed setup won't do this with any reliability if
sessions are done properly and wiretapping and spyware are kept
under control. Session IDs should be taken from a large enough
number space and generated randomly so they are not guessable.
>Trouble is, there are still some situations where it would be very
>useful to track usage of some HTTP-based service, or limit access,
>based on something like the older concept of a "session". One of my
>customers provides online access to a small, limited-purpose
>database, and until recently was able to maintain a simple
>fixed-rate billing-by-userID scheme. This works tolerably well when
>each userID comes from a single IP, but one of my customer's
>customers would like to allow multiple individuals access to the
>database from their internal network. Oh, and they'd like "instant
>access", that is, recognition of (say) their IP as one automatically
>authorized and not requiring an ID/password step to access the data.
That sounds a lot like "one page, one session, one charge". Remember,
if the users are taught to log out IMMEDIATELY (after saving the
results) to keep the number of simultaneous sessions down, they can
get a *LOT* of mileage out of one allowed simultaneous connection.
This suggests that the billing method isn't in touch with reality
and doesn't reflect value received.
>My customer would like some way of limiting access so that no more
>than N (initially one) of this customer's individual users is/are
>"accessing the database" at one time, so that usage past a certain
>limit will cost the customer more. Unfortunately, this idea of
>"only N simultaneous users" seems extremely difficult to implement
>cleanly in the HTTP environment.
Not only is it difficult to implement, it's difficult to even DEFINE
what a "simultaneous user" is.
>>From the server's point of view, each HTTP transaction is completely
>defined by its contents, and persistence is available only through
>the combined efforts of the browser and whatever "session memory"
>the server provides for the browser's use. In theory (translation:
>I haven't completely tested this) the server could distinguish
>multiple end-user browsers making requests through the same IP
>because each browser would be assigned a different "session ID", but
>given the expected short duration of HTTP transactions (in this
>case, on the order of seconds) it would be very unlikely for the
>handling of transactions from different browsers to overlap.
Exactly. Consider charging per query. Or charge per significant
query (if it takes getting through 3 pages to do a query, charge
for the final one that gives useful results).
>Limiting the number of simultaneous "sessions" (in the PHP sense)
>from a given IP is tricky. What defines when one browser's PHP
>"session" ends so the server can let another one be initiated? Do
Nothing. Maybe you should consider whether it is APPROPRIATE to
generate a large bill for someone who forgets to log out over a
weekend, but generates no activity during that time. And is it
really approprate to generate an even larger bill if one browser
does a few queries one year, the employee retires, and when it's
reactivated 3 years later, it still has the session open, so that's
three years of continuous connect time?
>you attempt to require that each end-user go through a "logout" page
>when they are done, something at odds with the user's experience
>with every other 'web site? (And do you set up a switchboard ot
>handle the complaints when half the end users go to lunch without
>bothering to "log out"? <grin>)
Why should going to lunch and forgetting to log out cost a lot?
>I came up with one promising approach using server-side persistent
>non-session storage (an SQL table, say) and a fixed "expiration
>time" (say 15 minutes). If the server stores the session ID, IP
>address, and a timestamp for each HTTP transaction the server can
>declare an "quota exceeded" condition (refuse to assign new session
>IDs) whenever a given IP address (or userID) has more than N
>"unexpired" entries in the SQL table. This comes _close_ to
>approaching the old idea of a "session", and I _think_ it can be
>done through straight PHP and xxSQL; that is, without having to
>rewrite any server internals <grin>. But it's really klugy, and I
>sincerely hope some better method exists.
>Am I spending too much time and effort studying trees instead of the
>forest?
Yes. You're trying to charge for man-hours in the forest when the
value received is how much they remove in logs to be turned into lumber.
Professional loggers get a bargain and the Cub Scouts get charged
a huge amount for one tree.
>Is there some other way (or ways) of looking at the problem
>of charging for access that would be a better fit for data access
>through HTTP?
Pay-per-query. Either a fixed amount, some measure of how much
data is returned, or a combination of both. For example, the
subscription says that for $x a month, they get 500 queries per
month, after that it costs $y per additional query. Or make it a
per-day or per-week limit. No need to count individual users (only
what subscription they have access under) at all.
Think: what kind of behavior do you wish to ENCOURAGE? Don't
charge extra for that. What kind of behavior do you wish to
DISCOURAGE? Charge extra for that. What kind of behavior gives
the customer value? Charge for that. Assume the customer will (or
at least may) modify his behavior to reduce his bill.
BAD: The user logs in, does a query, logs out quickly. Repeat as
necessary. This costs 3 hits on your server compared to
staying logged in.
GOOD: The user stays logged in for a few hours worth of queries, then
logs out.
BAD: The user logs in, issues one query which returns 50 GB, then
uses it all day. Repeat next day. This is hell on your
bandwidth.
GOOD: The user issues queries with a small amount of data returned,
all he needs to use for that query.
Gordon L. Burditt
- Next message: Fidelita Munos: "Timestamp from a Third Party"
- Previous message: jblanch: "Re: General question on charging for data access"
- In reply to: Frnak McKenney: "General question on charging for data access"
- Next in thread: Frnak McKenney: "Re: General question on charging for data access"
- Reply: Frnak McKenney: "Re: General question on charging for data access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
