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

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Pif Paf

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

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

    #2
    Re: TCP servers in Python - two processes want to use same port

    Pif Paf wrote:[color=blue]
    >
    > The child process is a very simple program using SimpleHTTPServe r. 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.[/color]

    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

    Comment

    • Nowan

      #3
      Re: TCP servers in Python - two processes want to use same port

      Pif Paf wrote:[color=blue]
      > 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 SimpleHTTPServe r. 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[/color]
      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.




      Comment

      • Pif Paf

        #4
        Re: TCP servers in Python - two processes want to use same port

        Peter Hansen <peter@engcorp. com> wrote in message news:<403A248D. 47B51ECE@engcor p.com>...[color=blue]
        > Pif Paf wrote:[color=green]
        > >
        > > The child process is a very simple program using SimpleHTTPServe r. 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.[/color]
        >
        > 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.[/color]

        I will give that a go.
        [color=blue]
        > 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.[/color]

        Clearly the operating system knows, so there should be a way to find out.
        [color=blue]
        > If you do know, though, as your test
        > harness probably does, can't it just "kill -9" the thing?[/color]

        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

        Comment

        • Irmen de Jong

          #5
          Re: TCP servers in Python - two processes want to use same port

          Pif Paf wrote:[color=blue][color=green]
          >>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.[/color]
          >
          >
          > Clearly the operating system knows, so there should be a way to find out.[/color]

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

          --Irmen

          Comment

          Working...