I have a Windows Server Application that accepts connections from many
client devices (RF networked WinCE machines) via TCP/IP. We run
multiple copies of the server app, listening on different ports and on
different machines and connection requests are Load Balanced through a
central point. Once a connection is established, it is maintained for
the duration of certain tasks on the client end, which will later
terminate the connection and request a new one.

The Load Balancer we are using to distribute connections has the
ability to detect whether the app is running and listening (I'm not
sure how, perhaps someone knows the basic principle behind this?) and
will not send connection requests to an instance that is down.

I would like to have the option in the server application to stop
listening for new connections, so that the Load Balancer will not send
new connection requests to that instance, but at the same time
continue reading and processing activity from previously existing
connections - up until the client closes the connection.

Any tips from a general standpoint on how to do this?

The server app itself is written in Delphi 2007 using the provided
Socket components. Obviously, I would be quite happy to accept
from a Delphi sockets expert, but I will take general suggestions as
well.

Thanks!
Kimberly

kimmerkc <kkohler@peapod.com> wrote:
> I have a Windows Server Application that accepts connections from many
> client devices (RF networked WinCE machines) via TCP/IP. We run
> multiple copies of the server app, listening on different ports and on
> different machines and connection requests are Load Balanced through a
> central point. Once a connection is established, it is maintained for
> the duration of certain tasks on the client end, which will later
> terminate the connection and request a new one.
>
> The Load Balancer we are using to distribute connections has the
> ability to detect whether the app is running and listening (I'm not
> sure how, perhaps someone knows the basic principle behind this?) and
> will not send connection requests to an instance that is down.

It may be noticing the RST/ACK response to a SYN request and concluding
there is no app listening at the given destination IP/port number and so
routes to another machine. And/or it notes that no SYN/ACK response has
returned after some amount of time. Other possibilities exist - those are
just guesses.

> I would like to have the option in the server application to stop
> listening for new connections, so that the Load Balancer will not send
> new connection requests to that instance, but at the same time
> continue reading and processing activity from previously existing
> connections - up until the client closes the connection.
>
> Any tips from a general standpoint on how to do this?

The first possibility that comes to mind is to modify the app so it closes
the listening socket(s) when it no longer wants to accept more connections.
You can safely close a listening socket without affecting any already
established sockets a process has open. And the process should be able to
re-open the listening socket(s) when it is again ready to accept more
connections. All without affecting previously existing connections. Getting
the code logic right may be simple or involved, depending on how modular
the existing listen and accept code was written.

On Sep 25, 10:31 am, kimmerkc <kkoh...@peapod.com> wrote:

> The Load Balancer we are using to distribute connections has the
> ability to detect whether the app is running and listening (I'm not
> sure how, perhaps someone knows the basic principle behind this?) and
> will not send connection requests to an instance that is down.

Read up on how to use your load balancer properly. Trying to get the
application to stop listening just to get the load balancer to move
load elsewhere is a very poor solution. Consider if your servers are
attacked and all servers do this because they think they are receiving
too much load.

If your load balances is so hopelessly broken that breaking your
application's ability to accept clients is the only way to get it to
move clients elsewhere, then you have a hard and painful job ahead of
you. You will need to get all your servers to coordinate who has the
most load so only those servers stop listening. (Otherwise, again,
under high load conditions, you may wind up with no servers accepting
connections.)

Except this is what the load balancer is supposed to be doing already.

DS

On Tue, 25 Sep 2007 16:29:41 -0700, David Schwartz wrote:

> Read up on how to use your load balancer properly. Trying to get the
> application to stop listening just to get the load balancer to move
> load elsewhere is a very poor solution. Consider if your servers are
> attacked and all servers do this because they think they are receiving
> too much load.
>
> If your load balances is so hopelessly broken that breaking your
> application's ability to accept clients is the only way to get it to
> move clients elsewhere, then you have a hard and painful job ahead of
> you. You will need to get all your servers to coordinate who has the
> most load so only those servers stop listening. (Otherwise, again,
> under high load conditions, you may wind up with no servers accepting
> connections.)
>
> Except this is what the load balancer is supposed to be doing already.
>
> DS


you get $200 for this shite?

Blow me.
--
Meanwhile, the dope pipe laid there on the bed screaming 'HERE I AM!
HERE I AM!

On Sep 25, 6:29 pm, David Schwartz <dav...@webmaster.com> wrote:
> On Sep 25, 10:31 am, kimmerkc <kkoh...@peapod.com> wrote:
>
> > The Load Balancer we are using to distribute connections has the
> > ability to detect whether the app is running and listening (I'm not
> > sure how, perhaps someone knows the basic principle behind this?) and
> > will not send connection requests to an instance that is down.
>
> Read up on how to use your load balancer properly. Trying to get the
> application to stop listening just to get the load balancer to move
> load elsewhere is a very poor solution. Consider if your servers are
> attacked and all servers do this because they think they are receiving
> too much load.
>
Oh, I am actually thinking of a manual process for maintenance
purposes. I want to give my Support staff the ability to rotate a
server instance out of the pool without endangering existing
connections, perform necessary maintenance when all the previously
connected clients have disconnected, and then add it back in to the
pool. For normal operations, the Load Balancer does an excellent job
of keeping connections... balanced.


On Sep 25, 1:37 pm, Jim Logajan wrote:
> The first possibility that comes to mind is to modify the app so it closes
> the listening socket(s) when it no longer wants to accept more connections.
> You can safely close a listening socket without affecting any already
> established sockets a process has open. And the process should be able to
> re-open the listening socket(s) when it is again ready to accept more
> connections. All without affecting previously existing connections.

Thank you. This is all I needed to know. Since it is so hard to
reproduce a production-like load of connections I wanted to find out
in advance if such a modification was worth the effort of trying.

Kimberly

On Sep 26, 8:41 am, kimmerkc <kkoh...@peapod.com> wrote:

> Oh, I am actually thinking of a manual process for maintenance
> purposes. I want to give my Support staff the ability to rotate a
> server instance out of the pool without endangering existing
> connections, perform necessary maintenance when all the previously
> connected clients have disconnected, and then add it back in to the
> pool. For normal operations, the Load Balancer does an excellent job
> of keeping connections... balanced.

Just test it to make sure it doesn't cause a problem for connections
that come in immediately after it stops listening. I think it's
probably better to make an easy way to tell the load balancer to stop
sending connections to that server, but closing the listening socket
should work just fine. Be warned, you may not be able to re-open it
for a bit if you don't set SO_REUSEADDR.

DS

Unfortunately it turns out that Delphi's implementation of
TServerWinSocket.Close "fully" kills all client connections. I'm
not having much luck circumventing this with Delphi objects. I'll
look into Indy, but in the mean time, can anyone provide me with some
Windows API (Winsock) code (C/C++ style is fine or whatever language
you use) to Close and Reopen a listening socket?

I'm new at using the WinAPI directly, but eager to learn.

Thanks!
Kimberly

>>> On 9/27/2007 at 4:25 PM, in message
<1190931907.147096.62830@50g2000hsm.googlegroups.c om>,
kimmerkc<kkohler@peapod.com> wrote:
> Unfortunately it turns out that Delphi's implementation of
> TServerWinSocket.Close "fully" kills all client connections. I'm
> not having much luck circumventing this with Delphi objects. I'll
> look into Indy, but in the mean time, can anyone provide me with some
> Windows API (Winsock) code (C/C++ style is fine or whatever language
> you use) to Close and Reopen a listening socket?
>
> I'm new at using the WinAPI directly, but eager to learn.

Are you saying that if you close the listener socket it also closes all
connected sockets that were 'spawned' from that listener socket?
Seems to me to be bizarre behavior, to say the least!

Frank