TCP servers in Python - two processes want to use same port

[Pif Paf]

I am writing programs that will run as TCP servers. Briefly, I want to
set up a TCP server on a port in such a way that if another server is
already sitting on that port (both servers are Python programs I will be
writing), the old one is booted off (and its process ended).

My master process is a test harness, which tests a script which as part
of its functionality sends http GET messages. My test harness sets up
an http server as a child process, by creating an instance of
popen2.Popen3().

The child process is a very simple program using SimpleHTTPServer. The
problem is when I run my test harness, break it with Ctrl-C then try to
run it again. The http server complains that it cannot bind to the socket,
as the address is already in use.

My production system will use several http servers (I'm using http GET
messages as a simple form of inter-process communication), and I don't
want to have a situation where a program runs one time (because it's
asking to bind to a port that isn't already in use), but the next time,
it doesn't run because the port is being used.

Now of course I could use files to describe what ports are currently in
use and what process ids are using them, and kill the process before
trying to re-use the port, but that solution strikes me as inelegant.
Is there a better way? For example, is there a way of writing a program
that will force binding to a port, and if an existing process has that
port will kick it off (and possibly destroy it)?

--
Pif Paf

[Peter Hansen]

Pif Paf wrote:

The child process is a very simple program using SimpleHTTPServer. The
problem is when I run my test harness, break it with Ctrl-C then try to
run it again. The http server complains that it cannot bind to the socket,
as the address is already in use.

I believe you should be looking at SO_REUSE_ADDR as a means of rebinding
to a socket that was just used recently and may still be active at the
OS level, even if the app that used it has exited.

As for the specific question about ways to kill the app that is listening
on a socket already: I think if you don't know which app it is, there
isn't a clean way to find out. If you do know, though, as your test
harness probably does, can't it just "kill -9" the thing?

-Peter

[Nowan]

Pif Paf wrote:

I am writing programs that will run as TCP servers. Briefly, I want to
set up a TCP server on a port in such a way that if another server is
already sitting on that port (both servers are Python programs I will be
writing), the old one is booted off (and its process ended).

My master process is a test harness, which tests a script which as part
of its functionality sends http GET messages. My test harness sets up
an http server as a child process, by creating an instance of
popen2.Popen3().

The child process is a very simple program using SimpleHTTPServer. The
problem is when I run my test harness, break it with Ctrl-C then try to
run it again. The http server complains that it cannot bind to the socket,
as the address is already in use.

My production system will use several http servers (I'm using http GET
messages as a simple form of inter-process communication), and I don't
want to have a situation where a program runs one time (because it's
asking to bind to a port that isn't already in use), but the next time,
it doesn't run because the port is being used.

Now of course I could use files to describe what ports are currently in
use and what process ids are using them, and kill the process before
trying to re-use the port, but that solution strikes me as inelegant.
Is there a better way? For example, is there a way of writing a program
that will force binding to a port, and if an existing process has that
port will kick it off (and possibly destroy it)?

--
Pif Paf

I think you might have better luck in a TCP networking group, as this
isn't really a python question (unless python has some nify TCP api).
you might check into Twisted to see what's there for nifty apis.

If you're talking unix, you might want to spawn both servers as children
of the same parent. after launching both servers, the parent just waits
as a manager process. when the second child is unable to acquire the
port, it can signal the parent. the parent can send a stop/kill signal
to the child.

signaling a process requires the process id (pid). the children don't
know each others process ids. but they have their parent's process id.
The parent gets the process ids of all children.

not sure how that would apply in windows. don't think windows even has
signals. if so, you would have to substitute some other form of
interprocess communications.

[Pif Paf]

Peter Hansen <pe***@engcorp.com> wrote in message news:<40***************@engcorp.com>...

Pif Paf wrote:

The child process is a very simple program using SimpleHTTPServer. The
problem is when I run my test harness, break it with Ctrl-C then try to
run it again. The http server complains that it cannot bind to the socket,
as the address is already in use.
I believe you should be looking at SO_REUSE_ADDR as a means of rebinding
to a socket that was just used recently and may still be active at the
OS level, even if the app that used it has exited.

I will give that a go.
As for the specific question about ways to kill the app that is listening
on a socket already: I think if you don't know which app it is, there
isn't a clean way to find out.
Clearly the operating system knows, so there should be a way to find out.
If you do know, though, as your test
harness probably does, can't it just "kill -9" the thing?

The test harness typically does know the process. However, if the test
harness stops without doing proper cleanup (e.g. deleting a child processes
it has created), then when it is restarted there will be "debris" from
the last run that is stopping it from running properly. This is not,
perhaps, a big issue when it's just the test harness, but it is a major
issue on the production system. If the production system goes down for
any reason, I want to be able to bring it back up again by typing one
command from the command line. This will run the master process, which in
turn will restart other processes, and it is not acceptable for an old
process to be clogging up a socket.

--
Pif Paf

[Irmen de Jong]

Pif Paf wrote:

As for the specific question about ways to kill the app that is listening
on a socket already: I think if you don't know which app it is, there
isn't a clean way to find out.

Clearly the operating system knows, so there should be a way to find out.

The OS knows a lot more than your user space applications, and that
is a good thing, for security reasons.

--Irmen