Subject Re: [IBO] limiting concurrent users
Author staff@belding
Hello Luiz

----- Original Message -----
From: Luiz Alves <cprmlao@...>
To: <IBObjects@yahoogroups.com>
Sent: Sunday, July 08, 2001 8:40 AM
Subject: Re: [IBO] limiting concurrent users


> This solution dosen´t works when you have a procedure taking a long time
to
> execute.

Do you mean the login/refresh-the-login procedure or some other procedure
which takes a "long time"?
The login/refresh-the-login procedure I use is tiny and takes "little" time.

> I also need a solution to this and my workaround was:
> Create an app running on server, checking and authorizing news login on
> database.
> In my case, all my clients use static ip´s. So, I create a inifile with
all
> static ip´s in my LAN that can access the database. On login, the client
app
> connects to app server via socket and I check(on app server) if the remote
> ip is on list of ip´s on inifile. if ok, I allow the client app login in
> database, otherwise I send a message to client app to deny entry.
>

That's a nice way to handle logins. Do it once at start up of your app on a
client and if the client IP address is not in your ini file do not allow its
use. It seems this method applies to "limiting clients to certain machines"
and it could also be used to "limit the number of concurrent users" by
counting the current users. However you have not said how you handle this,
particulalry you need to ensure an IP address listed in use is actually in
use and was not disconnected last Friday by accident and not removed from
the active IP list, if your max-concurent-user count is less than the number
of permitted IP users.

In the case I have the application is a packaged application to be installed
from a CD to a network. So I do not know identifying details about either
server or clients. Also the app does not limit which clients access the
database, rather it limits the number of clients currently acccessing the
database. The app is priced according to the number of concurrent users,
hence the need to enforce an upper limit on "concurrent users".

The method I suggested is also in use with a 16 bit Delphi Paradox Table/BDE
application and works OK at a site with 20 concurrent users on a 10Mbs LAN
with win9x clients.

I guess we are off-topic here as the only connection with IBO is that we are
using IBO as our connection to IB ......

Best wishes

Russell


> ----- Original Message -----
> From: staff@belding <russell@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Thursday, July 05, 2001 12:30 AM
> Subject: Re: [IBO] limiting concurrent users
>
>
> >
> > ----- Original Message -----
> > From: Geoff Worboys <geoff@...>
> > To: <IBObjects@yahoogroups.com>
> > Sent: Thursday, July 05, 2001 1:39 PM
> > Subject: Re: [IBO] limiting concurrent users
> >
> >
> > > > As I am about to deliver a nice little software running
> > > > over interbase, I am now in the situation where I have
> > > > to limit the number of concurrent users logged into some
> > > > tables (but not all the tables).
> > >
> > > Users do not "logon" to individual tables - databases yes, but not
> > > tables.
> > >
> > > I think the best you can hope to achieve is to build something into
> > > your client application that logs access details when a form is
> > > openned, and clears when a form is closed. Of course this will mean
> > > problems when the application aborts or the connection fails for some
> > > reason ..[...]
> >
> > Here is a simple method I use:
> >
> > Suppose your applications know when a user is in the place where they
need
> > to register as a concurrent user.
> >
> > When in that zone your timer runs an update procedure every 5 minutes,
> say,
> > saying the users is still logged in to the zone.
> >
> > When the user exits from the zone log them out by running a procedure on
> the
> > server.
> >
> > When a user first logs into the zone delete any logged in users whose
> update
> > is 6 or more minutes old, and log the user into the zone. Count the
> current
> > number of zone users and do your prevent access logic.
> >
> > The times need to be tuned to your application and your restrictions.
>