in reply to Port duplicator

What kind of port are you talking about? I was recently in Portugal, in the city of Porto and at the river (near the port), they served interesting wine, called portwine.

But even if we restrict the discussion of ports to a computer, there are at least three ports commonly used that spring to mind:

If you are talking hardware, I would suggest a hardware solution. Either plug in the test system into a different port of the computer, or splice the cable to connect to two machines.

If you are talking software, there are various ways of doing what you're interested in, at least if I understand what you are actually interested in.

I interpret your statements in the software sense as having some software that expects to talk TCP/IP on a fixed port number. You want to make two (or more) instances of that software coexist on the same machine, preferrably on the same network adapter.

If you cannot change the port number (the easiest way), you can maybe use your operating systems facilities. The *BSD family of operating systems has convenient port redirection facilities (even available as Perl module). If you cannot do this redirection (transparently) within your OS, you might want to look if you can run your local program via inetd which can launch a new process for every incoming connection.

If that solution does not seem what you want, maybe you can specify what you want more clearly in terms of a comparison to POE, or Apache, or HTTP::Proxy, or even netcat.

Thanks to calin for spotting various typos.

Replies are listed 'Best First'.
Re^2: Port duplicator
by tweetiepooh (Hermit) on Sep 28, 2005 at 13:14 UTC
    Yup, there are lots of ports (for boats), ports (wine), ports (conversion to new platform), ports (hardware) and ports (soft). That's what makes asking google so much fun. We are talking IP ports here.

    Source server has a tcp/ip port out of which it spews data. Currently local software connects to that port, processes the data into a database. Source port only allows single connection and we can't play with it.

    Our idea is to have something running locally that will connect to source port, via TCP/IP, and then present the data to 2 local TCP/IP ports. Current software will then connect to one of these local ports. The other port is then free to connect another version of the client software, receiving the same data and the first.

    One idea is to have the local port act as a forking server so we can connect lots of clients, each would receive the same data. It's the sort of thing you'd use tee for on pipes.

    PS, all servers will be running Solaris. The source server and client software are proprietory code we have no control of. We can configure the client to connect to any source ip/port combination.
[reply]

      The idea of using/creating a tee for ports is sound. The question remains on how to "best" implement it.

      Let me first make a few definitions as I'm confusing the terms a bit:

      Let the "remote server" be the machine that spews forth data on a single port. Let the "local server" be the program "tee for ports" you're trying to find/write. Let "client" be the program(s) that currently listen to the "remote server" but which you want to listen to the "local server".

      As it seems that your machine will spew forth its data without interaction, I (personally) would prefer "prerecorded" test sessions that can be replayed to a client, more like cat for ports than tee, but that effect can be easily achieved by writing the spewed data to a file from a specialized client and then having a simple looping local server spew data from a file, both more or less using sysread. Such a thing could also be implemented using netcat I think.

      So, let's now look at the premade wheels for a tee implementation. Let's assume that the clients will connect at an unspecified time and will also disconnect without telling the local server, likely because of a program crash. The local server should still serve the data to all remaining clients and not stall because one client isn't writeable anymore. Maybe it should also only store a fixed amount of data for any client before it considers the client dead, to prevent memory exhaustion.

      As we don't want to stall, the simple use of IO::Tee won't work, as it will block if the data can't be written to a specific client immediately.

      You could use threads together with Thread::Queue to distribute the incoming data from the remote server to all connected clients. This is likely the easiest way if you have a multithreaded Perl.

      If you have an unthreaded Perl, you could look at creating a multiplex server using POE with POE::Component::Proxy::TCP and some tee-logic. Personally, I would avoid POE in this case and write my own multiplexer using select or IO::Select and do the buffering and distribution of packets manually.

[reply]
      Sorry, but there are no such things like "IP ports". IP is a network layer that hasn't the port concept, which is supported in TCP and in UDP. The fact that you talk about "TCP/IP" later does not help to clarify the matter - simply because the protocol stack is usually referred to as "TCP/IP", but UDP is part of the stack as well.

      Why bother about this distinction? Simply because using TCP or UDP could modify dramatically your mileage. You don't say how the intermediate machine is going to take the data, for one thing. Or which sub-connector will be the leader of the main connection, to say another.

      The whole mechanism is also quite obscure. You say that "local software connects to that port, processes the data into a database". But later you tlak about having a second client "receiving the same data and the first". There's a model ambiguity here. In the first case the model is more like a pull, in which the client enters and asks for some particular data inside the database. In the second we have something more similar to a push, in which any client is presented the very same data at every session.

      The latter case if of course by far the simplest. You only have to connect, download the data, then wait for any connection in other ports. OTOH, the former case is full of pitfalls, because you're basically asking a way to correctly interleave the requests coming from two clients over the same connection, which depends on the particular application.

      Flavio
      perl -ple'$_=reverse' <<<ti.xittelop@oivalf

      Don't fool yourself.
[reply]
        Sorry if it's not clear. I used the term IP port to distinguish that it's not a place of refuge for boats, a fortified wine, a hole on the back of the machine and so on.

        I am also unsure of the exact mechanism but it seems to be a push. The current software connects to the remote port and receives data which it processes and passes to a database. The system is such that there can only be a single connection to the remote port. That is controlled at the remote end and we have no control of that.

        The idea is to have a local program that makes the connection to the remote system and simply pipes the information to two (or more) local ports so we can connect more than one copy of the current software to the data stream. If there is more to the connection than this then it will not be worth the effort to fix it and we will carry on as we are. One idea I had was that if I make the local port act like a forking server in some manner maybe I could make the local connections more "dynamic" rather than fixing to 2 or more fixed port numbers.

        To recap, the new tee program will replace the current software in connecting to the remote system. The current software will connect to the tee. The tee will do little bar act as a tee. If the tee does need to pull data it will do so and pass the data to it's outputs. I don't think that the current clients do more than suck data. All the tee will do is present that "flow" to more than one point.
[reply]

In Section Seekers of Perl Wisdom