Board index » delphi » To Disconnect or Not to disconnect

To Disconnect or Not to disconnect

Hi,
    I'm trying to design an C/S application and I have a question about
keeping the connection alive or reconnecting for each request. I do not
anticipate more than (let's say 50-100) users using the program at a time.
Should I keep the connection alive or reconnect every time a new request is
made? -- on an average I would say there is going to be 1-5 minutes between
each request. (the application is going to run in a LAN)

Thank you.

 

Re:To Disconnect or Not to disconnect


Quote
"Peter Zolja" <csu10...@mail.claytonstate.net> wrote in message

news:3d4d81be_2@dnews...

Quote
> Hi,
>     I'm trying to design an C/S application and I have a question about
> keeping the connection alive or reconnecting for each request. I do not
> anticipate more than (let's say 50-100) users using the program at a time.
> Should I keep the connection alive or reconnect every time a new request
is
> made? -- on an average I would say there is going to be 1-5 minutes
between
> each request. (the application is going to run in a LAN)

> Thank you.

How big are the data packets expected to be? Would UDP be more feasible?

--
Corky
www.corkyscave.com

2.0 Beardies, 1.0 Burms, 1.1 {*word*76}s, 1.1 Carpets, 2.1 B.C.I.s, 1.0 B.R.B,
1.0 Royals, 1.1 Hoggs, 1.1 Hognoses, 1.0 Pueblan Milk, 1.0 Cali King, 0.0.2
Corn, 1.1 Garter
and a big ass spider

Re:To Disconnect or Not to disconnect


Quote
>     I'm trying to design an C/S application and I have a question about
> keeping the connection alive or reconnecting for each request. I do not
> anticipate more than (let's say 50-100) users using the program at a time.
> Should I keep the connection alive or reconnect every time a new request
is
> made? -- on an average I would say there is going to be 1-5 minutes
between
> each request. (the application is going to run in a LAN)

Hard to tell...
I would go for the disconnect version, since this will reduce
traffic/connections on the server side (although this should be no problem
with 50-100 connections, but you might want to increase that...).
On the other hand, if there's some sort of authentication, it might be more
easy to keep the connection.
But considering the farly large time between the single requests, I guess
disconnecting would be suited better here...

Just my 2 cents.

Andy

Re:To Disconnect or Not to disconnect


Quote
> > Hi,
> >     I'm trying to design an C/S application and I have a question about
> > keeping the connection alive or reconnecting for each request. I do not
> > anticipate more than (let's say 50-100) users using the program at a
time.
> > Should I keep the connection alive or reconnect every time a new request
> is
> > made? -- on an average I would say there is going to be 1-5 minutes
> between
> > each request. (the application is going to run in a LAN)

> > Thank you.

> How big are the data packets expected to be? Would UDP be more feasible?

What I expect are packets between 1-5k... There are going to be many
requests within a relatively short period of time (30-60s), and then
probably some long pauses... The reason I'm asking is because I will have to
implement some sort of login method as well... (i.e. not everybody is
welcomed :)
I'm not sure how UDP would change the whole picture...

Re:To Disconnect or Not to disconnect


Quote
> >     I'm trying to design an C/S application and I have a question about
> > keeping the connection alive or reconnecting for each request. I do not
> > anticipate more than (let's say 50-100) users using the program at a
time.
> > Should I keep the connection alive or reconnect every time a new request
> is
> > made? -- on an average I would say there is going to be 1-5 minutes
> between
> > each request. (the application is going to run in a LAN)

> Hard to tell...
> I would go for the disconnect version, since this will reduce
> traffic/connections on the server side (although this should be no problem
> with 50-100 connections, but you might want to increase that...).
> On the other hand, if there's some sort of authentication, it might be
more
> easy to keep the connection.
> But considering the farly large time between the single requests, I guess
> disconnecting would be suited better here...

Is connecting going to take a lot of time? I use a few CS programs (no clue
how they are made) in which the connecting part (after you enter your
username + password) takes a few seconds... I wouldn't want to make them
wait if I don't have to... (these programs run in a LAN); thanks.

Re:To Disconnect or Not to disconnect


Quote
> Is connecting going to take a lot of time? I use a few CS programs (no
clue
> how they are made) in which the connecting part (after you enter your
> username + password) takes a few seconds... I wouldn't want to make them
> wait if I don't have to... (these programs run in a LAN); thanks.

The delay is usually because of a queue system, or the overhead of a backend
database
checking the username/password pair. In a small system like you describe, if
you code
clever enough there should be no noticable delay.

/A.

(ps: reminder to all about the Indy Live Q&A Monday night !)

Re:To Disconnect or Not to disconnect


Quote
> > Is connecting going to take a lot of time? I use a few CS programs (no
> clue
> > how they are made) in which the connecting part (after you enter your
> > username + password) takes a few seconds... I wouldn't want to make them
> > wait if I don't have to... (these programs run in a LAN); thanks.

> The delay is usually because of a queue system, or the overhead of a
backend
> database
> checking the username/password pair. In a small system like you describe,
if
> you code
> clever enough there should be no noticable delay.

What do you mean by "clever enough"? I was thinking of choosing the middle
ground: to keep the connection alive but if there is not activity for let's
say 2 minutes, it should disconnect. BTW: where do you think would be a
better place to check this, in the client side or server side?

Thank you.

Re:To Disconnect or Not to disconnect


Quote
> What do you mean by "clever enough"?

I don't know what Allen means with "clever enough" of course, but if your
authentication scheme is implemented in a way that allows the server to
quickly decide whether or not a client is allowed, then there should be no
delay.

Quote
> say 2 minutes, it should disconnect. BTW: where do you think would be a
> better place to check this, in the client side or server side?

Generally, I would suggest the server side, as normally a server should be
"powerful" enough to decide when a client will be disconnected or not. On
the other hand, this system normally only makes sense for servers that deal
with clients that the programmer has no control of (like HTTP servers or
so). If you develop both client and server and your server will only have to
deal with your clients, you might as well let the client decide when to
disconnect...

Andy

Re:To Disconnect or Not to disconnect


Quote
> What do you mean by "clever enough"? I was thinking of choosing the middle
> ground: to keep the connection alive but if there is not activity for
let's
> say 2 minutes, it should disconnect. BTW: where do you think would be a
> better place to check this, in the client side or server side?

> Thank you.

I've had to develop a solution to a similar problem. I defined a server side
record that stores login info for a set lease period. Each client logging in
is verified the first time and given some kind of registration number that
it passes back when it accepts user - the record is then added to an
internal list. For example client IP address, userID, password, registration
code. Those values are always passed to the server when a request is made
and checked against the list. Reverification is only done when lease
expires. It sorted my problem anyhow :).
--
Corky
www.corkyscave.com

2.0 Beardies, 1.0 Burms, 1.1 {*word*76}s, 1.1 Carpets, 2.1 B.C.I.s, 1.0 B.R.B,
1.0 Royals, 1.1 Hoggs, 1.1 Hognoses, 1.0 Pueblan Milk, 1.0 Cali King, 0.0.2
Corn, 1.1 Garter
and a big ass spider

Other Threads