Hello all.

I am working on some web/networking ideas for Pick type databases. This
leads to two questions that hopefully some folk with experience can help
with please...

D3 sockets
I read that RD have implemented license restrictions on processes which
use sockets. In other words a process attached to a socket burns a user
license. Is this all sockets (client, server and I/O) or just server
sockets. Does this put D3 at a disadvantage for Web/HTML applications?

mvBase
Does mvBase provide network sockets? If I have mvBasic programs that
need to talk to the outside world (say HTML or two systems communicating
via network) for example.

Any information, links or tips you can share would be very much appreciated.

Thanks in advance.


John Bend

John,

If you were looking at using Phantoms/sockets as a means of
side-stepping licences, then yes, that loophole has been closed. This
also extends to people who used "tricks" like logging onto an account
that :

* fired off a phantom
* logged off
* had the phanton attach to the device that kicked it off

As always, there are things that you could do, but RD may need the
money to keep the doors open, so please pay them what they ask.

That said, perhaps they will move to a different licence strategy one
day so that they COULD effectively compete in the WWWorld - but I'm not
holding my breath 'cause I can see that this would see their revenues
(and viability) plummet

John, we've had several exchanges on this in the past. If you want
connectivity with D3 or mvBASE, you know I can do it, but it won't be
free and it won't give you a 10-to-1 user/license ratio either.

John wrote:
As phrased, that question has a (probably unintentional) wide scope.
D3 isn't at a disadvantage by any means. You can support any average
web site on a minimal number of connections. For better or worse,
none of the FlashCONNECT sites that I've setup require more than 5
licenses, usually only two for an intranet or until they build
momentum for outside use. If you're getting traffic comparable to
EBay then sure you'll need more licenses but then you wouldn't have a
problem with an extra couple hundred dollars to pay for licenses.


Agreed. I think John's issue is that he's writing tools and doesn't
want his clients to have to consume/purchase licenses in order to use
his software. Hey, we're all in the same boat. The only way to
justify bypassing or reducing end-user license consumption is if you
can prove that your value-add software will actually encourage more
license purchases with across the board. We have products in our
market that are helping to do that. IMO, most attempts at cost
reduction like this are just intended to increase near-term VAR
income, and that just puts another nail in the MV coffin.

I think a change to the "right" model will preserve a revenue stream.
The per-seat license model died long ago. I'd still advocate a model
based on some combination of disk, bandwidth, and/or hits. Most
people don't like the pay as you go model, but we have no complaints
applying it to phone, gas, electric, auto gas/petrol, etc. We pay to
ship packages and truckloads of goods on a per-use basis, why is
electronic data any different? And for phone there is the "unlimited
usage" plan, which is also used for some connectivity software like
ColdFusion, and it would easily work for larger MV shops as well.
Until someone proposes something that will work then we can't expect
the MV vendors to modify their old pricing structures. I don't recall
any firm proposals in these forums, just a lot of complaints about
licenses costing too much.

T

Thanks Tony and Ross.

Please don't run away with the idea that I am furtively working on a way
to cheat Raining Data. Actually my modest hope is that my work will
benefit the MVDBMS community when completed. This is part of my MSc project.

I am trying to get an understanding of "who does what" with sockets in
the MVDBMS vendor world. So far I know that D3 offer a somewhat troubled
support for network sockets within the FLASHBasic language. Whilst I
hear that there are D3/socket licensing issues I have yet to determine
exactly what these are. I know that UniVision and jBase provide
excellent support for network sockets as free evaluation versions are
available for these products. I still have NO idea what is offered by
mvBase - if anything.

Can anyone please enlighten?

Thanks again.


John


Tony Gravagno wrote:

Hi Tony,
<SNIP>
D3 isn't at a disadvantage when compared with what? Other MV platforms
maybe? I would love to be able to use a MV backend for my web work and
perhaps I am missing something but licensing costs have thus far
prevented me from attempting this.

To help me grok the situation, does this mean that these sites never
have more than five simultaneuos visitors? Or is the user -> license
ratio something other than 1:1?

What happens if a site has say, 1/100 of EBay's traffic? 1/10?

Under US $500.00 would cover license needs for traffic on an EBay
scale? If this is even close, _please_ let me know and I will surely
reconsider.

Thanks in advance,
-Tom

On 14 Aug 2005 11:56:19 -0700, "Tom deL" <ted (AT) blackflute (DOT) com> wrote:

Socket built-ins will always be problematic when you look at
portability. The unique exception is if you develop your own TCP stack
within MVBASIC and make the connection directly into the VME instead
of through a network subsystem based on the O/S. Doug @ ModSoft has
done that with the Pic-Lan product. It's very stable and something you
should look at if you're that devoted to having sockets inside MV. I.
personally, would put the socket connectivity outside of MV simply for
better control and future expansion.

I have 8 FC ports running and only about 3 of them are in use at any
given time. We have ~150-200K hits per day with about 20-30K of those
being FC. Typically, 3 of the 8 are in use while 2 more spill over
when there's a heavy instantaneous spike. The key to developing on a
live data platform is to mix dynamic content with static content. You
can squeeze a lot of data activity out of a few slots if you don't
abuse the connectivity.

Even $5000 for a set of licenses is nothing, if your web sales are
bringing in $5K a month in profit. You'll pay for that one-time
license fee within 4 weeks of operation. I think a lot of people
totally miss the high-margin ROI aspect of web sales when they're
costing out web technology. If you poorly integrate web sales into
your business model, then you'll definately end up stretching the ROI
out a lot longer.

On the flip-side, if your integration is for intra-office
functionality then the cost of integration can only be offset by the
time/wage savings of streamlined procedures that the web model
implements. Just making something "web based" doesn't automatically
make it cost-effective in cash-flow.

Glen
http://mvdevcentral.com

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Glen:

You and I both know the licensing model for all mvDbms products exists in
the stone age. Because of this, use of the mvDbms products for web work,
which is really cool and useful, is limited. They're killing their own
market by myopia.

I have more problems with the mvDbms model because of licensing issues than
for any other reason!

Bill

"Glen" <nospamwebmaster (AT) all-spec (DOT) all-spec.com.com> wrote

Summary response here.

John - no, mvBASE doesn't have a socket interface and I believe RD no
longer supports FlashCONNECT over mvBASE either because of lack of
demand. Your options for mvBASE include mv.NET, a custom protocol
that rides over telnet, or a file system interface which handshakes
with other environments with UWRITE and UREAD of data and
instructions. This last method is precarious for reasons I've
documented in CDP and our e-mails. You may also be able to use Coyote
or PicLan-IP with mvBASE 1.x, not sure about 2.x or whether this is a
wise choice due to platform support issues (I'm sure this isn't worth
Doug's time anymore).

Tom et al - I'm providing a more comprehensive response because these
questions seem to keep coming up. I hope it helps someone without
boring too many of you.

Remember that FlashCONNECT can be used in a persistent or
non-persistent mode. A simple non-persistent transaction request can
be handled in 100ms and depending on network connectivity that means a
turnaround for the client of as little as 250ms to about 1 second - of
course it can be much worse with slower connections, larger in/out
data volumes, HTML rendering, images, etc etc. The point so far is
that the actual transaction time is very short.

I never write any web interface in a persistent mode, as this will tie
up a D3 connection for a single user. This is the typical mode that
we all use for telnet/serial lines and this is the 1:1 user:license
model. When you are non-persistent you get an n:1 ratio because
multiple users are hitting and releasing in an alternating fashion.

Consider the following example which shows two processes (each line
below is a process, each satisfying requests from separate users (each
number is a unique user number).
134668
222577
What that shows is that over some period of time the first port
handled requests from 5 users and the second handled 3 requests. I
repeated numbers to show that some requests take longer than others.
A total of 8 requests were handled by these two ports. Let's assume
that each time slice is 500ms. So in the first 1 second, the first
port handled two users (1 and 3) and the second only handled 2/3 of
the the request from user 2. During the first second, let's say user
4 posted their request, but both ports were occupied with users 1 to
3. User 4 must simply wait until a port is available, but they only
have to wait about 500-1000ms. If all users 1 to 8 simultaneously hit
their Submit button, they would wait in the queue to be processed by
whichever port happened to be available. Notice that overall, 2 ports
satisfied 8 users in a period of 3 seconds. With better server
performance or more efficient app code, this can be reduced a bit to
achieve that 100ms-250ms turnaround.

The chances of 8 people hitting Submit at exactly the same moment is
pretty slim for all but the most active sites: Google, Amazon, travel
sites, etc. Even in such a case, a turnaround of 3 seconds to submit
a page of data is not unreasonable to the average web user. But the
above documents a moment of high activity. Most activity occurs
during the course of a day where people hardly notice the odd instance
of 3 second response vs 2 or 1 second response. There can be high and
low periods of activity where people will recognize the difference.
If the high activity times become painful, that is when you need to
consider adding extra ports. A third port for the above scenario
might get you port distribution like this:
1466
2228
3577
Here we see turnaround time reduced to 2 seconds for the same 8 users
with the same transaction times.

When I say 8 "users" I don't mean 8 people visiting the site, I mean 8
people hitting Submit at the very same instant. The site can have any
number of simultaneous visitors, let's say 1000, but most users are
looking at data and filling in fields, they aren't all clicking that
submit button at the exact same time.

Not all hits come in through the back-end server either. As users
surf around you'll get better "performance" from your server if you
minimize the actual activity required on the back-end. Pages that
don't require regular updates should be static. For example a product
catalog that displays part#, description, and pricing should be posted
to the site as a static page and updated periodically on a schedule
(during low traffic periods). Only transactions requiring dynamic
data and responses should be hitting the server. This is what allows
ratios of 100:1 or 1000:1 for visitors:licenses.

Another way to improve performance is to use server pools (with
FlashCONNECT, mv.NET, PDP.NET, Web Wizard, etc) so that low-priority
transactions hit the slower pool and high priority requests hit the
fast lane. For example, management requests shouldn't come in through
the same port as general product requests from the net. And people
clicking the "Buy Now" button should probably use a unique pool
altogether.

Some newer applications will constantly hit the server with tiny
transactions, vs the older one-time Submit of an entire page.
DesignBais as one example does field-level processing, so the server
is constantly hit with events and data validation requests. In this
case, you need to make sure that your back-end logic is fast because
you're intentionally driving your server to process more transactions
per second. Well, if you're asking your system to handle those
massive transactions then you need to give it the resources to handle
them. ASP.NET works exactly the same way, with lots of small
server-side rules being fired while a user is working on a page, and
the newer AJAX does the same thing. We can't expect this new
transaction-oriented paradigm of client-server computing to function
with the same minimal resources as page-at-a-time processing.

Many companies often use different servers to respond to specific
types or requests. You can do the same with any MV web connectivity
if you coordinate your back-end for it. You can have one MV server
for casual surfers and one for real busines transactions. Or use
ASP.NET or any other technology you want to interface to SQL Server or
MySQL and only hit the MV server when required. Update the
middle-tier as required with product changes. I have one client doing
just this, getting reasonable traffic with only MS Access on the web
server.

Back on the EBay analogy, most MV sites don't get anywhere near EBay
traffic. Unless we really have that much traffic we shouldn't pretend
that we have the same needs because such posturing only muddles the
discussion. A realistic needs assessment will allow us to come up
with some real numbers in terms of licenses and cost required to
support the traffic for a given company. For those larger companies,
again I don't see what the big deal is with an extra couple hundred
dollars per port, progressively incrementing the licenses as required
to support the business. If you're getting that much traffic then you
can afford it. If you're getting a ton of traffic and not making any
money then you have business issues, not technical.

Once again I'm consuming way too much bandwidth. What do you think so
far?

T


"Tom deL" <ted (AT) blackflute (DOT) com> wrote:

Hi Glen,

You sorta missed the point ... but let me play Devil's Advocate
(Imagine that! LOL)

<SNIP>

First, I am _not_ devoted in any way to having sockets inside MV.

Sockets aren't (weren't) the point of this. MV licensing schemes which
assure that their products won't be used were the point.

So not even a blip on the screen of the EBay scale volume Tony
mentioned.

OK. Now you are approaching the point. Most of my sites do 'abuse the
connectivity'. Silly little things like shopping carts, forums, links
pages, guestbooks, portfolios and the like use pages dynamically
created from database entries.

This isn't really as if I am driving a huge SUV as a grocery getter
though because I use php and mySQL or pgSQL.

Why should 'abusing the connectivity' even be an issue? For the
convenience of having the PICK data model? That _is_ mighty handy but
can I in good faith ask my clients to fund my desire for handiness?

For that matter pgsql contains some of the data model functionality
that comes into play in this discussion.

The fact that picksource.com, mvdevcentral and other sites devoted
to MV development do not take advantage of MV backends. A little
like using a Cadillac to promote your Ford, eh? Or Bill trotting
out a G4 to hype his latest Windoze wonder (at least it wouldn't
lock up during the demo :-/)

Since you are in a position to answer: Do you suppose that the reason
for this was the superiority of the tools or the difference in
licensing costs?

<SNIP>

Although that might be considered chump change to some developers, it
is a far cry from 'an extra couple hundred dollars'.

What does this $5000.00 buy for my client? The extra time I have to
spend doing a left join instead of reading values costs a tiny fraction
of that. And I get the cash ;-) And I get a security model that
actually _means_ something. And known risks because I am using standard
tools that have been exposed to the bad guys for years.

<SNIP>

Hmmm, I thought that there was a direct correlation between these ;-)

-Tom
http://www.blackflute.com/music/

Hi Tony,

Thank you for this.

<Tony's excellent description of needs analysis SNIPped>

Now that I have played Satan's Cochran to Glen:
It is dawning on me that we are looking at this from very different
points of view. I would like very much to be able to use some sort
of PICKlike in my everyday work - so I am looking at this as 'what
tools make sense'. You (and Glen and seemingly most of the PICK
community) seem to be looking at it as the Golden Goose: Something to
be handled with great care and used sparingly.

Your suggestions above (server pools, being stingy with connectivity)
while sound, are things which are driven (in the context of this
discussion) largely by licensing issues.

Whoa up there a minute, big fella. The original hyperbole of EBay
and < $.5k was yours. In your OP you seem to have the attitude that
a web site will be either the web site of a typical company using
MV or an EBay.

I host several sites that while not on an EBay scale do considerable
traffic (.7gb - 2.5gb/day, hits in the M's/day). In these sites I use
mySQL heavily: from presenting and providing content to interactively
detecting and blocking dictionary attacks. These dictionary attacks
alone can generate hundreds of hits per second.

<Devil's Advocate>
But ... why? What value do these fees offer to my client?
</Devil's Advocate>

I do appreciate your comments above. On the other hand it doesn't
mitigate the issue enough for me to begin incurring these costs.

One thing that I will attempt when time allows: A program to analyze
my mySQL logs with an eye to concurrent connections.

Thanks for your input,
-Tom