Re^3: Port duplicator

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.

Comment on Re^3: Port duplicator

Replies are listed 'Best First'.
Re^4: Port duplicator by tweetiepooh (Hermit) on Sep 29, 2005 at 08:49 UTC
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]
Re^5: Port duplicator by polettix (Vicar) on Oct 01, 2005 at 10:27 UTC
Ok, you still don't clarify this definitively but I assume you're talking about TCP ports. Moreover, I assume that the information flow is only from the remote server towards the connecting client, i.e. there is no single byte from the client to the server. You talk about `tee`, which is uncapable of sending data in the standard input of the process that's sending the output. This said, you should also clarify: When your tee progam connects, does it have to start reading from the remote server at instance, or wait for incoming connection? Does it have to cache all the traffic coming from the remote host, and give it to any connecting client, or does it have to drop the traffic as soon as it is (possibly) delivered? In the second hypotheses in the previous bullet, is it ok for a client to jump in the middle of a communication? Will the initial data make sense? Is it sufficiently robust to handle this? As you see, these considerations put different requirements on what you're asking for - in one case, for example, you have to cache, but not in the other. One big difference I see with the `tee` application is that the latter knows in advance which files it has to send output, while you're asking for something that should cope with the possibility of a client connecting at any time. Flavio perl -ple'$_=reverse' <<<ti.xittelop@oivalf Don't fool yourself.	[reply] [d/l] [select]