> 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 don't mean login but refresh login. If in any time in your client app, you
execute a query taking a long time(maybe some minutes), your app doesn't
have the opportunity of refresh the list of clients connected using a timer.
If you use BDE or a DBMS, all your actions and procedures accessing the
database are short there is no problem.

> 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.

Here is what I do. The unique way that I found was using hard key choiced
for me. I buy this hard key and distribute to client or the own client can
acquire it.
I use then the serial number of the hardkey(this is the only thing I need of
this key) and I compose a string cryptographed with:
serial_number(from hardkey)+date_of_validate_of_app+number_of_users.
I distribute this crypto string to client.
I ditribute to client a service app where the client needs put on list in an
inifile all ips of your LAN and on start up of this service app(used to
manage logins via socket), I check first if there is a hard key on parallel
port. If ok, the service app verify if the serial_number distributed to
client is equal to serial number readed from hardkey on parallel port. After
this, I read the amount of ips on inifile and compare with the amount
distributed to client via crypto string. If this amount is less than one,
all is ok and the the service app can start work normally expecting
connections from client app. Otherwise, it doesn't start.
When a client connect to my service app, it verifies if the remote ip is on
the list of the inifile filled and the acesss will be authorized depending
it.

So, I don't need control if there is a crash on workstation or if this ip
was used or not.
The only thing that I need to authorize a client app works well is:

serial_number(from hardkey)=serial number distributed on my crypto string
date_of_validate_of_app<=date of today
number_of_users>=number of users filled on inifile
remote ip is listed on inifile.

> database. The app is priced according to the number of concurrent users,
> hence the need to enforce an upper limit on "concurrent users".

My problem is the same.

I think the main problem is: to allow a client log in your database, the
response of the server(or service) app needs to be in real time. There is no
time to expect a timer running and count how much clients are connected to
decide if a client can access the database.

> > > 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.

It works if you don't need quick response and a hard control of amount of
users accessing the app.


Luiz.

----- Original Message -----
From: staff@belding <russell@...>
To: <IBObjects@yahoogroups.com>
Sent: Saturday, July 07, 2001 9:16 PM
Subject: Re: [IBO] limiting concurrent users


> 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.
> >
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>