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.