We have an application which uses phantom ports with socket calls similar to
processit.
But now with the new D3 licensing for 7.4, we are now charged a user for
each phantom that uses listens on a socket.
Has anyone run into this problem and found a solution to it.
Any suggestions for alternative methods that don't involve ODBC or
purchasing another product such as FlashConnect.
Thanks.

Bob,

This isn't a "problem" that needs a solution ! It is RD enforcing their
licence more closely than they have in the past. If you have a process
that talks to the outside world, then RD would like you to pay for
that.

Whilst the 'value' may be a point of contention, if YOU (or your users)
have been benefiting from using D3, RD would simply like to be
recompensed - just as I'm sure you ae being paid for the use of your
software.

I don't mind paying RD, IBM etc for the use of their database
technologies Like everyone, I'd prefer the seat pice to be lower & have
options for CPU based licences, but I really don't see that this would
do anything other than lower their revenue stream, and my business
NEEDS them to stay in business!

I really wasn't looking for a philospohical discussion here, just some ideas
of what my options are.
But if I must I will explain. The socket aspect of our software is not
something we've sold.
It's just an idea to inteface the old shareware processit with our
application framework if a client wants to have a web interface.
When we sell our application, we typically provide a 30-50 user sale to RD
so please don't preach to me about this.
I don't mind paying RD for their database but I'm trying to make our
software a viable solution for businesses.
As RD keeps raising prices, it just makes it that much harder to sell b/c of
the overhead.
As far as I understand RD's licensing policy, they are trying to avoid
people writing terminal servers where I agree licenses are being stolen.
But a web application where there's also 50 licensed users on the system
using terminal emulators is where they are throwing out the baby with the
bathwater.
What happens if during a busy season, this businesses web application starts
to run out of connections constantly because we just can't handle the load?
They'll always have to have enough users to run enough phantoms to handle
the max even though most of the year, they might not even need half that
number of users.
Charging for a web connection is one thing but it shouldn't be full price.
Why don't they charge for every odbc connection?
Should I pay full price for an odbc connection to interface with UPS
software? They've made provisions for that, why not the web?
The database is pricy enough. It's not a smart idea to make it more
expensive to access data from the web when so many applications need to move
in that direction.

I want RD and other mv vendors to stay in business just as much as you do.
It's the best database model there is. But this is just another example of
how they are following in Pick's footsteps and making it harder on us to
sell their product.
Now if web applications were going to start costing RD licenses b/c users
would use that rather than terminal emulators, then I could really see your
point. But web applications don't cut it for running a business yet. You
still need conventional users.

I don't really know much about FlashConnect and if it's worth the price to
my clients. ODBC just falls way short of what we need.
jd3 looks like a nice product but that's now subject to the same licensing
"problem".




"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

Frank,

"As far as I understand RD's licensing policy, they are trying to avoid

people writing terminal servers where I agree licenses are being
stolen.
But a web application where there's also 50 licensed users on the
system
using terminal emulators is where they are throwing out the baby with
the
bathwater. "

Unfortunately, whilst there may be 50 'real' users on the system, RD
also want a piece of those 'pretend' web users too ! And, YES, if that
means you need to purchase more licences to meet peak demand, then you
are going to need to buy more licences.

I don't believe that putting Flashconnect into the equation will make
things any easier for you, as it still has phantoms that consume
sockets and so would require additional users to be purchased, as you
have also pointed out with JD3.

My understanding of JD3, and probably your own socket connector, is
that it doesn't scale well under load because there is no mechanism to
queue requests - if you don't have enough phantoms to respond NOW, you
are out of luck !

I suspect FC may be the same, but will happily be corrected :-) I know
we spent a LOT of time getting this "right" with Visage in the early
days, and had a single DB connection able to handle 300 'simultaneous'
requests before we started to have timeout issues

Whilst it probably IS possible to find ways around the licence issue,
you have to weigh up the time taken to develop these vs the cost of
simply buying extra licences - unless you are selling a LOT of systems
this probably will not stack up (send me an email & I can probably even
point you in the right direction if you want to run the risk of getting
RD off side)

Of course you can/should also voice your opinion directly to RD, as
should other 'impacted' parties that read this thread - unless you/we
all let our opinions be known, we cann't really blame RD for not taking
notice of them, can we :-)

Good point about queueing requests. That's the type of answer I'm really
looking for with my original question. Gives me some food for thought.
I'm an desktop app and network programmer, not so much a web programmer but
demands are being made to "web enable" the app which is where the need for a
cost effective solution comes in.
We could consider FlashConnect which would mean paying RD something but I'm
glad you mentioned that it also has the same licensing restriction so then
jd3 may be a better choice since it's open source.
Makes me wonder why RD doesn't want a piece of the pretend users that can
interact with the database over odbc using coldfusion or php.
I'm sure you're right that there are ways to get around it. One thought I
had was putting the socket listeners outside of d3 and using a ram drive to
replace the socket in d3. Wouldn't be a hard tweak to jd3 or processit and
it remains to be seen if it would work well enough. Turning that ram drive
into a queue is a nice touch. But like you said, there's development and
debugging cost there. The hope is for many installations down the road so it
would be worth the effort to keep it's price a bit lower which could in the
long run benefit RD.

Now the critical part of my question really is just this..
If I can web enable this application with a few phantoms, say maybe 5 and
this thing will handle it then that's not so steep. But if the reality is
that I'll need 20 or 30 socket phantoms to handle this then we're starting
to price ourselves out of being able to do this.
In your experience or anyone's reading this, what is typical for a web
application that takes orders and does inventory queries?
Control would be in place to keep selects quick so that connections wouldn't
last for too long, but during this business's busy season, that load could
increase significantly. I'm trying to make some architecture decisions
regarding this and don't want to make a bad choice.
Thanks for your time.






"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

Also, my point in this wasn't to disparage RD. The MV model gives us many
advantages over relational systems.
Obviously I don't agree with this policy and maybe a few others but I too
want to see RD do well and believe in the product.



"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

No EASY/accurate answer on this one (ratio of web users to your
phantoms), because there are also issues of 'acceptible perfomance',
which I know from our Visage users will vary per company (and sometimes
day of the week !). In some cases a single DB connection can service
Do you have an idea of transaction rates, and also PEAK transaction
rates ? The PEAK is the critical issue !

Using Visage as an example, you can fairly easily service around 4.5
million 'hits' to the database over a 24 hour period with just 10
database connections doing 'real stuff' (mechanically this means that
each HIT would be serviced in 1/5 second), BUT if your peak transation
HIT rate was 6,000/minute you would need 20 connections, and a faster
machine for the database & web server !

Now you are talking about a machine with a fairly hefty workload,
because depending on WHAT is going on, this hit rate may well
correspond to 10,000 active users, or possibly just a few hundred -
obviously depends on the content of the page, and how long between
screen refreshes.

I'm not suggesting that Visage is capable of supporting 10,000 (real!)
USERS from 10 database connections, BUT I would suggest that if I had a
site with THIS volume of traffic, throwing 100 users onto a big
multi-processor IBM with SAN storage should not be out of the question
!

My guess is that the volume you REALLy need is closer to a few hundred
hits/minute, so with the right architecural BITS, 10-12 DB connections
should be AOK

We wrote socket comms for multiple clients to connect to phantoms years
ago - it is on u2 and uses the GCI. You can now have socket coms in
unibasic but we are no converting cos of the licence - i am sure you
have an equivalent in D3 to the GCI, you just have to write your socket
code in c and call it. the licencing model then does not know you are
using sockets.

On 06 Jun 2005 17:30:59 EDT, "Bob Frank" <bgf (AT) jgatech (DOT) com> wrote:

http://mvwww.mvdevcentral.com

This is an on-going project, but it is quite functional at the
moment. I have not load tested it under harsh conditions, but from
what I've seen it should handle a decent load with only a few phantoms
on a nice Linux box. Some of the code has been ported to Windows, if
you really have to run it.

File spooling is used to manage the requests and responses. There
is a two-path one-way file FIFO-like setup that each phantom can pop
the stack on and process requests from. This allows new phantom
processes to be started and stopped at any time without breaking
current activity. I'm still working on an XML module, but I'm hoping
to have a bare XML DOM API working by the end of the year.

You have to consider your web deployment as either:

1) Internal functionality to make employees more efficient at their
jobs.

2) External functionality to provide more interactive functionality
for customers, which will raise revenue and reduce internal call
center overhead.

How your applications are designed and where they are deployed will
determine if an open source solution is really worth the lack of
commerical testing and support. Regardless, you will have to use
phantom licenses. FlashCONNECT does a great job for HTTP
implementations. Most of the major bugs are gone now and it runs very
quickly. The only reason I started the MVWWW project was to provide a
cross-flavor platform that is equally quick in passing
request/repsonse data. I also wanted to make it a lot more flexible so
that other content, such as XML postings and direct injections of
requests, could be handled. The biggest complaint I have about FC is
the HTTP form post/get restriction. Other than that, it runs our
e-commerce center well. I have an average of 4 or 5 phantoms active at
a time. I have 8 total dedicated phantoms. We get around 100K-150K
page and image hits a day. FC gets 2-5 hits per second on an average
day. Based on our yearly web revenue, the cost per phantom seat per
year is extremely low when you compare automated web orders with phone
orders that can require 10 minutes to an hour of a rep's time. If you
don't utilize web technology to streamline processes, then you have to
make up for the costs elsewhere.

Glen
http://mvdevcentral.com
http://picksource.com

If a PIB license is consumed by a phantom running a socket, that's not
too bad, considering the socket can be used to serve the needs of many
users, one at a time, but in quick succession. This is consistent
with FlashCONNECT which does consume D3 licenses even though it's run
on phantoms, and this usage does not violate the RD EULA. So running
nothing but socket clients you can get n-to-1 users per PIB license

What gets me about this, and again I haven't done any tests yet, is if
a phantom consumes a PIB license then you lose both the PIB and the
phantom. I wouldn't mind at all if they consumed a PIB license without
consuming the phantom license too. So a 20 user system could
conceivably run 15 phantom/sockets and 5 telnet PIBS, but still have
20 phantoms available for normal phantom use. Does anyone think this
is unreasonable? I think this model it's quite equitable.

Has anyone actually checked the behavior in a recent 7.4 release?

All that said, considering the hassles associated with sockets in
general I don't recommend anyone use them unless you really know how
to handle them (geeky pun sort of intended).

T

m buller <mabull_er_ (AT) jonaco (DOT) com> wrote: